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

カテゴリ「📋」に属する投稿[13件] - 今日のひとことログ

更新

■LOG カテゴリ「📋」に属する投稿[13件]

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

No.4198 〔230文字〕 📋

通信可能な容量が「1GB」という表記の場合、1,000MBのことを指す会社も多い中、1,024MBのことだと解釈している会社は良心的である。なお、MB(メガバイト)やGB(ギガバイト)だと1,000単位なのか1,024単位なのかがハッキリしないので、そこをハッキリさせたMiB(メビバイト)やGiB(ギビバイト)という単位がある。1GBだと1,024MBの場合と1,000MBの場合があるが、1GiBだと1,024MiB一択である。分かりやすいが発音しにくい。

No.3584 〔1413文字〕 📋

『20歳から60歳までの40年間ほど民間医療保険の保険料(月1万円)を払うと、60歳の時点で払い込んだ保険料は元本が全額返ってくる上で、医療保障は一生涯続く』という保険商品があるらしい。そういうのを見たときには、なぜ保険会社はそれが可能なのかを少し考えた方が良い。40年間で元本は合計480万円になるが、月1万円の積み立てで合計480万円を自分で40年間も運用できたら、利益はいくらになるか計算してみよう。仮に年率4%で運用できたとする(4%はかなり控えめな値だ)と、元本480万円に対して、収益は約702万円になる(つまり合計1,182万円)。年率5%で運用できた場合は収益が1,046万円(合計1,526万円)だ。40年間もの長期間で運用できれば、複利の恩恵でここまで増える。先の保険商品では、この収益分が丸々保険会社に入ることになるのだ。契約者には元本である480万円だけを返せば良いからである。保険会社は実際にはもっとうまく運用するだろうから低くても年率7%は余裕で超えるだろう。その場合、収益は2,144万円(合計2,624万円)になる。だからこそ、「元本をそのまま全額返還した上で、医療保障は一生涯」という保険商品が作れるのだ。最初に述べた年率4%での運用というのは、長期的な視点で見れば、ノーロード(=販売手数料無料)のインデックスファンド(世界分散か先進国分散等の投資信託)を使えば充分達成できる年率である(ただし、日本では収益の20%は税金で徴収される点に注意。しかし一定額まで税金が掛からない制度もある)。さて、先に述べた保険商品を契約した方が良いと思えるだろうか? もしかすると「元本が全額返ってくるなら損はしないのでは?」と思うかもしれないが、「現在の1万円」と「40年後の1万円」では価値が異なることに注意する必要がある。今、自動販売機で缶ジュースを買うと1本120円~130円くらいだが、40年前にはいくらだったか。もちろんこの40年間には大きな経済成長があったので、向こう40年間にそこまでの爆発的な成長はないだろうが、だからといって40年後も缶ジュースが1本120円ということはないだろう。成長率は低くとも成長はするのであれば、お金の価値は徐々に下がっていくのだ。「1万円」というお金の価値は、40年後には今の価値よりももっと下がっているはずである。「元本がそのまま返ってくる」というだけなら、額面ではなく価値として見れば、減っているのだ。複利での運用が力を発揮する最も重要なポイントは「長期間」なので、若ければ若いほど有利なのだが「銀行の定期預金が最も堅実」みたいに考えてしまっている人々も多そうに感じる。先の保険商品は途中解約不可な契約だそうだ(解約するとそれまでに払い込んだ保険料は返ってこない)。知識の少ない若いうちに「元本が全部返ってくるの!? お得!!」みたいな感じで契約してしまったら、気付いたときには解約しにくくなっているだろう。運用については、「インデックスファンド」・「ドルコスト平均法」・「つみたてNISA」という3つのキーワードの意味を調べると良い。今ではネット証券会社を使えば手続きも契約も運用もとても簡単なので、間違っても銀行の窓口で相談してはいけない。運用(複利)の重要なポイントは手数料を極限まで排除することだが、今の銀行は手数料で儲けるビジネスモデルだからだ。

No.3573 〔577文字〕 📋

ググってから、どこのWebサイトに移動することもなくその場で目的が完了するというケースが増えてきたような気がする。以前からちらほらあったのはあったけども、頻度は上がっているような。
20210409103957-nishishi.png
上図でGoogleが抽出しているページの場合、実際のページでは「手順番号+箇条書き+画像」の列挙で構成されているので、Googleはページの一部をそのまま抜き出しているわけではない。もっとも、実際のページでもul+li要素を使って、HTML的には箇条書きの構造は使われているのだが。だからこそGoogle側も抜き出せているのだろう。(ただ、この場合に最も望ましいのはul+li要素ではなくol+li要素だと思うが。) 企業サイトの場合はこのような形で消費者へ簡潔に情報が伝えられればそれに越したことはないので、「Googleに正しく抜き出されやすいHTMLの書き方」みたいなものはもっと重要になっていくのだろう。例えば、手順はol+li要素で記述した上で、間に余計な記述(装飾目的だけの項目とか)を加えないとか。上図の場合、Googleページ上では8ステップまでしか掲載されていないが、実際のページでは18ステップまである。なので、その点を誤解なく伝えるには、最初のタイトル部分で「~の手順」だけではなく「~の手順 18ステップ」みたいに数も併記しておく手はありそうだ。

No.3218 〔399文字〕 📋

Googlebotのクロール頻度を下げる方法は、Googleによる解説がある。Google側がクロール頻度(最大頻度)を指定できる設定ページを用意しているが、90日間しか有効ではなく、90日後には自動判断に戻ってしまう。何より、今回クロール頻度を調整したいのは、外部WebサービスのAPIリクエスト権に上限があることが原因なので、「APIを利用せずに出力できるページのアクセスを制限する必要はない」という点があるのでクロール頻度(の上限)そのものを指定する方法はあまり適切ではない。Googleの解説にはもう1つ「緊急クロールの制限」として、「負荷の増大を動的に検出して対応できるならHTTP 429を返せ」と書かれていたので、今回はその方法を採用した。API利用権の残数が少なくなってきたときに、APIを利用しないと出力できないページにアクセスされた場合にだけ、429を返すようにPHPを書いた。

No.3217 〔593文字〕 📋

外部WebサービスのAPIを利用して生成しているサイトをメンテナンスしようと思ったら、今度はGooglebotが結構な頻度でアクセスしていた。これは狙っていたことでもあって、動的に生成したサイトマップXMLを少し前にGoogle Search Consoleへ登録しておいた影響だろう。ただ、予想以上にアクセス頻度が高かった。APIの利用権を半日で使い果たしてしまうくらいの頻度だったので、ちょっと制限することにした。「1日のAPIリクエスト数がXXXX回を超えたらAA%ブロック(=HTTPステータスコード429を返す)し、YYYY回を超えたらBB%ブロックする」というように、具体的なリクエスト総数に応じて多段階にブレーキを掛ける仕様にした。よく考えれば最初からこう作っておけば良かったのだが。この方法なら、API利用権を使い切ってしまうこともなく、余らせすぎることもなく、良い感じに自動運営ができそうな気がする。やや心配なのは、HTTP429を返す期間が長すぎると、Google側が学習してアクセス頻度を大きく低下させてしまう可能性があるかもしれない点だが。極端な話、「午前中(AM)はアクセス可能で、午後(PM)は完全ブロック」のようになりかねないので、1日の後半のHTTP429数の多さだけから学習されてしまうと困る。Google側も24時間単位で考えてくれるなら良いのだが。

No.3210 〔994文字〕 📋

確定申告完了。帳簿はもっと前から完成していたのだが(今回は還付申告にならないので)2月16日にならないと手続きができなかったので待っていた。本当は昨日にする予定だったのだが、気力が沸かなかったので今日に。青色申告を始めて10年以上が経つのだが、初めて還付ではなく納税になった(=源泉徴収によって払いすぎた税金を取り戻すのではなく、こちらから国に税金を納める)。昨年は源泉徴収されている種類の収入の割合が低かったのが要因だ。いつもなら還付金額が表示されるところに、今回は納税額が表示された。(´・ω・`)
20210217230340-nishishi.png 20210217225445-nishishi.png
「こちらからの納税ってどうやるんだ?」と疑問に思っていたのだが、特に心配する必要はなく電子申告完了後に詳しい案内があった。まあ、税金を取る側が説明を用意しないわけがないよな。案内の最初に「銀行振替」が書かれている上に、一度手続きすれば次回からは手続きが不要というので素直に銀行振替にしようかと一瞬思ったのだが、振替日がずいぶん先な上に、何らかの原因で引き落とせなかったら延滞税が加わるようなことが書いてあったので、それなら手動で納付した方が安心だと思ってオンラインバンキング経由で即納付しておいた。なお、クレジットカードでも納税可能なのだが、クレジットカードで払う場合にだけ手数料が余分にかかる仕様だった。(結果的にはオンラインバンキングでも充分手間はなかったので、カード決済を選択する理由はあまりなさそうに感じた。カード決済は、オンラインバンキングが可能な銀行口座を持っていない人向けだろう。)
20210217225501-nishishi.png
国税庁サイトにマイナンバーカードでログインして閲覧できるメッセージボックスに届いた情報(上図)によると「オンラインバンキングを使う場合は銀行サイトで以下の通り入力せよ」的なことが書かれていたのだが、実際に銀行サイト上で操作するとこれらの情報は一切入力不要だった。特に「納税用確認番号」は入力欄がないどころか確認画面にも出てこなかったが良いのか……?(^_^;) たぶん、これらの情報は「自力でペイジーを使う場合」の話であって、この画面から直接ボタンクリックで銀行サイトに遷移した場合には不要なのだろうと解釈したのだが。
そういう若干の不安点がありはしたが、操作手順が分かっていればすんなり手続きが完了するだろう仕組みはできていた。ほぼボタンクリックだけで納税まで完了したのだし。

No.3146 〔98文字〕 📋

ここ数日間の微調整で、APIリクエスト数は6時間で16%くらいに落ち着いた。このペースなら1日(24時間)で64%くらいなので充分な余裕を持たせつつも、使わなさすぎることもなく良い感じな気がする。

No.3140 〔314文字〕 📋

私が管理しているとあるウェブサイト(ここではない)で昨日にBotからのアクセス頻度を制限するようフィルタを調整したところ、APIリクエスト数を6割減くらいにまで削減できた。ちょっと制限しすぎたかな、と思わないでもない。Bingbot(=Microsoftの検索サイトBingから来るクローラー)が凄まじく大量にアクセスしまくっていたことに驚いたのだが、robots.txtに制限(Crawl-delay)を書くだけであっという間に制限に従ってアクセス頻度を低下してくれたことにも驚いた。さすがにMicrosoftの名前を冠してアクセスしてくるだけあって、(デフォルトの行儀はともかく)明示的な制限にはきっちり従ってくれるようだ。

No.3132 〔873文字〕 📋

クローラーがrobots.txtを頻繁に読んでくれるのは(設定値がすぐに反映されそうで)嬉しいのだが、bingbotはなぜ1日に70回もrobots.txtを読んでいるのか。googlebotは1日に4回だった。平均を取ったわけではなく、ある特定の1日のサーバログを見ただけだが。robots.txt以外の全ページを含めたアクセス回数では、bingbotは10,785回、googlebotは3,958回だったので、bingbotは全クロールの0.65%をrobots.txtの読み込みに使っており、googlebotだと0.1%である。bingbotのアクセス頻度が高すぎるので、とりあえずrobots.txtに「User-agent: Bingbot、Crawl-delay: 30」の記述を加えてみた。1日に70回も読んでいるなら、約20分以内には制限を反映してくれるものと期待しているのだが。これでアクセス頻度が落ちなかったら、プログラム側で(何回かに1回の割合で)HTTPステータスコード429を返すようフィルタを作る必要がありそうだ。Bing Webmaster Toolにはクロール時間帯を調整する機能はあるのだが、総数を抑制する機能はないっぽい。なお、googlebotはrobots.txtx内に「Crawl-delay」を書いても読まない(解釈しない)らしい。そういえばGoogle側のドキュメントには、クロール頻度を調整したければHTTPステータスコード429を返せばそのうちGoogle側が学習してアクセス頻度を落とすとか何とか書いてあったような気がする。429ではなかったかもしれない。なお、ここのサイト(www.nishishi.com)の話ではない。ここのサイトは無駄なアクセスが多くても困らない(サーバの負荷さえ高くならなければ問題ない)のでログを調べていない。外部のWebサービスのAPIを利用してページを生成しているサイトでは、無駄なアクセスが多すぎると困るので、Botのアクセス頻度を調整する必要があるのだ。

No.3129 〔738文字〕 📋

とあるWebサービスのAPIには1日のリクエスト数に制限があって、それを超えてしまうとエラーが返ってくるようになってしまう。なので、リクエスト数を超えないよう調整が必要なのだが、このところリクエスト数が結構高いところまで増えてしまっていた。いま確認したら23時間29分の時点で95%を消費していた。ちょっとアクセスが集中したら権利を使い果たしてしまいそうな感じだ。本当にユーザが多いわけではなく、大半はbotからのアクセスだろうと思うのだが。いくつかの方法でbotからのアクセスを弾いたり頻度を制限したりしているのだが、何かそのフィルタをすり抜けるbotが増えてきたのだろう。早めにフィルタを追加した方が良さそうだ。放っておくと1日に数千回とかアクセスしてくるような悪質なbotが時々現れるので困る。(私が作っている)Webへのアクセスをそのまま(Webサービスの)APIに投げるようなことはしておらず、同じデータは一定期間(数週間)は1回しか取得せずに済むようにキャッシュを取っているのだが、それでも1日のリクエスト数が上限ギリギリになるとなると、相当なアクセス数になっているのだろう。サーバのログを見ないとハッキリしないが。今は「botのようだったらフィルタを通す」というようなプログラムを書いているのだが、これだといたちごっこになりがちなので、どうしても対処できなさそうなら「人間っぽくなければ全部フィルタを通す」というような方法にせざるを得ないかもしれない。マイナーなアクセス環境から来ていても正しく閲覧できるようにしたいと考えて前者の方法を採用しているのだが。後者の方法を採ると「本当は人間なのに弾かれてしまう」ケースが出てくる可能性があるので、最後の手段にしたい。

No.3086 〔333文字〕 📋

スクリーンセーバーキラーというUSB機器がある。30秒に1回の間隔でマウスを1ピクセル動かして戻すだけのハードウェアだ。商品説明には「本品はジョークグッズです」と書かれているのだが、レビューを読むと意外と役に立っているようだ。レビュー主がリモートワークで使用する会社のシステムは、セキュリティのために1分間マウス操作もキー操作もなかったら自動ログアウトしてしまい、再ログインには顔認証が必要で面倒なのだとか。このスクリーンセーバーキラーがあれば、30秒間隔でマウスが動くのでログアウトせずに済むとのこと。なんかもうセキュリティの教科書に載せたいくらいの典型的な「過剰に強すぎるセキュリティポリシーのせいで、逆に脆弱になってしまう」パターンが書かれていて笑った。(笑)

No.2424 〔498文字〕 📋

PHPの動作をローカルで確認したいときに、PHPに用意されている簡易ウェブサーバ機能を使う方法の分かりやすい説明があった。ここでは環境変数にphp.exeへのパスを登録する方法も解説されているけども、そこまでしなくてもコマンドラインからphp.exeをフルパスで指定すれば実行できる。たとえば、PHP実行ファイルがXAMPP内に存在するなら C:\xampp\php\php で起動できる。これをバッチファイル(.bat)に記述しておいてデスクトップにでも置いておけば、いつでも簡単にPHP(だけの)テスト環境を用意できて便利だ。この方法なら『c:\xampp\php\php -S 127.0.1.2:8080 -t D:\Path\To\Web』などとすると、D:\Path\To\Webをドキュメントルートにした簡易ウェブサーバが起動する。ブラウザからは 127.0.1.2:8080 でアクセスできる。複数のウェブ製作を並行して進めている場合、ドキュメントルートはプロジェクトごとにバラバラなので、こうやって指定できる方が楽かも知れない。必要なだけバッチファイルを用意しておけば済むので。

No.2225 〔613文字〕 📋

JR東日本の「Suicaでポイントが貯まる!」というTVCMが大阪の放送局で流れていて驚いた。関西人にもICOCAではなくSuicaを持たせようということか。しかし、関西圏にSuicaを購入できる場所があるのだろうか。あってもSuicaを持つメリットがなさそうだが。視聴者が「Suicaでポイントが貯まるならICOCAでも貯まるだろう」という連想をしてくれることを狙って(脱線事故以後)TVCMを一切流さなくなったJR西日本の代わりに東日本が流したのだろうか。そんなわけないか。しかし、TVでCMしても、日常的に電車に乗らない人が鉄道系の電子マネーを持つメリットは低いと思うのだが(もっとお得にポイントが貯まる電子マネーが他にあるだろう)。私が主な決済にICOCA(正確にはSmart ICOCA)を使うのは、それが定期券だからだ。常に持たざるを得ないカードであり、定期入れに入っていて財布よりも早く出せる上に、毎日通る改札機で残額を把握でき、駅の券売機でチャージできる利便性がある。日常的に電車に乗らない場合は、どれも利点にならないのではないか。なお、ICOCAではなくSmart ICOCAを使っているのは、クレジットカードと紐付けることで現金不要でチャージできる上に、クレジットカード側のポイントが貯まるからだ。SmartではないICOCA(=現金チャージのみ)だと電子マネーとして使うメリットはあまりなさそうに感じる。
2021年4月
123
45678910
11121314151617
18192021222324
252627282930
2021年5月
1
2345678
9101112131415
16171819202122
23242526272829
3031
2021年6月
12345
6789101112
13141516171819
20212223242526
27282930

Powered by てがろぐ Ver 3.4.0

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