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

カテゴリ「📖」に属する投稿(時系列順)[63件] - 今日のひとことログ

更新

■LOG カテゴリ「📖」に属する投稿(時系列順)[63件]

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

No.1951 〔669文字〕 📖

ネット銀行の中には、VisaとかJCBとかのクレジットカードブランドでのデビットカードを年会費無料で発行してくれる銀行がある。デビットカードというのは、クレジットカードのように使えるのだが、使った瞬間に紐付いている銀行口座からその額が引き落とされるカードのことだ。利用限度額は銀行口座にある残高までで、残高を超える決済をしようとすると拒否される。クレジットカードとは違って借金ではないため、カード発行に審査は要らないから誰でも作れる(年齢制限はある)。例えばVisaデビットカードなら、Visaのカード番号が発行されるので、Visaで決済できるところなら(たいていは)使える。デビットカード維持用のネット銀行口座を1つ作っておいて、その口座に少額だけを入れておけば、盗難などの不正利用時にも被害が抑えられて良いかなと思って、1つ作ってある。約3年前にメインで使っていたカードの不正利用被害に遭ってから作った。今は、特に初めて利用する小規模な通販サイト(たいていは小規模なお店で、メジャーな通販システムを採用せずに、自前のサイトでカード番号の入力まで受け付けているようなところ)では、必ずデビットカードの方を入力している。これなら、カード番号が漏洩する被害に遭ってもメインカードは守られるからだ。適宜(紐付いている銀行口座の)残高をチェックしておかないと、使いたいタイミングで使えない可能性はあるのだが、ネット銀行ならコンビニATMでもだいたい(回数制限はあっても)無料で入金できるのでさほどの不便はない。安全のための手間としては悪くない。

No.2175 〔363文字〕 📖

PCの電源を投入したらWindowsの起動ロゴが出た瞬間にCHKDSKが走り出した。
20200918182739-nishishi.jpg
完了してWindowsが起動してからCrystalDiskInfoで調べると、「代替処理済みのセクタ数」が10になっていた。前回見たとき(たぶん1ヶ月は経っていない気がする)は0だったので、一気に増えたのか。
202009181826561-nishishi.png
このHDDも電源投入回数は6,930回で、23,728時間(=988日くらい)も使っているのなあ。……と書いてみて思ったが、まだ使用時間的には3年は経っていないのだな。まあ、この値が増えないかどうか様子を見よう。
ちなみにこれはデータ格納用HDDであって、システムドライブではない。システムドライブはHDDではなくSSDにしてある。だからといって、もちろん壊れて良いわけではない。バックアップは取ってはいるが。

No.2188 〔70文字〕 📖

確認したら「代替処理済みのセクタ数」が11になっていた。2日前は10だったのに。
20200921002141-nishishi.png
HDDの交換を考えておいた方が良い気もしてきた。

No.2197 〔171文字〕 📖

国勢調査にネットから回答しておいた。行政サイトにしてはとても見やすくて簡単に利用できるサイトだった。
20200922095400-nishishi.png
「9月24日~30日までの1週間に仕事をしましたか」という未来の情報を過去形で尋ねてくる設問が微妙に気になったが。(回答は9月14日から可能だと書いてある。)ああでも、年は指定されていなかった気がするので未来とは限らないか。(笑)

No.2205 〔518文字〕 📖

メインPCのデータ格納用HDDの挙動がちょっと心配だったので、調達した新品2TB HDDと交換した。
20200924233242-nishishi.png20200924233242-nishishi.jpg
元のHDDは容量1.5TBだったのだが、今時新品で1.5TBという中途半端な容量はなさそうだったので、2TBを調達。6,800円くらいだったような気がする。SSDにしなかったのは、このメインPC自体が既に購入後10年以上経っていることもあって、メインPCではなくサブPC化する計画があるためだ。初期不良なく動いてくれれば良いが。データ用パーティションは毎日自動バックアップされる設定だし、前のHDDも別に壊れたわけではないので、突然初期不良で使えなくなっても大きく困ることはないが。しかし交換手続きは面倒だから、困るのは困る。以前のデータ用HDDはSeagate製7200rpmだったが、今回はWestern Digital製5400rpmにした。最近のHDDはたいてい充分静かだが、5400rpmだとなお静かかな、と思ったので5400rpmだ。旧HDDの電源投入回数は6,930回だったのだが、これを365で割ると約19になってしまう。電源投入回数から前回の交換時期を計算するのは無理だった。いつだったっけな……。

No.2206 〔280文字〕 📖

HDDを交換するためには、まず旧HDDから新HDDへパーティションをコピーしないといけない。そのためには一時的に両方のHDDを接続する必要があるわけで、ネジが6つ余分にないと困るのだということを忘れていた。
20200924233249-nishishi.jpg
……忘れていたのだが、道具箱を漁ったら充分な量のネジが出てきた。12個入りのパッケージの中にそのまま12個入っていたのもあったので、昔々に「ネジも必要だから」と思って買ったものの、充分なストックが存在することに気付いて、そのまま開封せずに道具箱の中にしまっておいたものだろう。今回はネジの必要性を忘れていたので、新たに調達せずに済んだ。(笑)

No.2207 〔440文字〕 📖

旧HDDから新HDDへのクローン作業は、日常的に自動バックアップ用途に使っているAcronis True Imageのクローン作成機能を使った。
20200924233254-nishishi.jpg
のだが、なぜかドライブレターを引き継いでくれなくて困った。旧HDDは先頭のパーティションから順に、Iドライブ→Tドライブ→Dドライブ→Eドライブ→Fドライブ→Vドライブに割り振っていたのだが、クローニングした新HDDを接続したら、頭から順にDドライブ→Eドライブ……Iドライブになってしまった。もちろんすぐに修正したのだが、システムファイルとかアプリケーションのキャッシュがIドライブに作成されるように作ってあったので、本来はVドライブになるはずのパーティションにキャッシュファイルがいくらか書き込まれてしまっていた。キャッシュの保存先に指定しているパーティションは、ドライブレターがそのままでは変更できないので、キャッシュの保存先を変更する操作が少々手間だった。なお、クローニングの所要時間は、だいたい1時間くらいだった。

No.2217 〔340文字〕 📖

また自宅の固定電話が繋がらなくなった! 2週間前に電柱に登って修理してもらったばかりなのに。どうなっているのだ、うちの電話回線……。ネット接続が電話回線に依存していなくて良かった……。過去2度の現象では「受話器を上げてもツーという音が聞こえず発信も着信もできない」というもので、それは今回も同じだったのだが、従来は「携帯電話から固定電話にダイヤルすると呼び出し音が聞こえる(固定電話側では鳴らない)」というものだったが、今回は「携帯電話から固定電話にダイヤルすると話し中の音が聞こえる」というもので、そこだけが異なる。あと、受話器を上げてから3~4秒後くらいにカチャッという謎の音が1度だけ聞こえる。これは受話器を上げる度に毎回する。何がどうなってそんな現象になっているのか……。

No.2218 〔114文字〕 📖

というわけで、またNTTの故障受付Webに情報を書いて送信した。前回は送信から1時間と掛からずにNTTから電話があったが、今日は日曜日だからどうだろうかな。まさか故障受付窓口が日曜日だから休んでいるということはないと思いたいが。

No.2219 〔208文字〕 📖

2週間前に来たNTTの修理担当者さんによると「ここはケーブルがあまり良くないようだが新品には交換できないので、また何かあったら電話下さい」とのことだったので、また故障すると予想できる何かがあるのだろうと思ってはいたが、まさか2週間で再度故障するとは。普段、電話を使うことが滅多にないので、たまたま今日気がついただけだから、実際には修理後1週間で故障していた可能性もある。そういえばここ1週間くらい着信がない気がする。

No.2220 〔55文字〕 📖

日曜日でも大丈夫だった。NTTの故障修理担当者は明日来てくれるらしい。果たして抜本的な解決ができるのかどうか。

No.2223 〔390文字〕 📖

NTT修理担当者が来訪。今回も電柱に登って電話しながら修理工事。自宅の固定電話は無事に繋がるようになった。しかし、使用するラインを変更しただけで抜本的な解決ができたわけではない様子だったが。担当者さんは、1週間以内に再度問題が起きたら事務所に直接電話をくれと名刺を置いて帰った。「113に電話するとたらい回しにされるでしょうから」とのこと。よく分かっている。(ちなみに固定電話が完全に繋がらない現象なのだから113へは電話できないのだが。)NTT西日本のロゴが入った名刺ではあったが、「(サービス運営業務委託社員)」と括弧付きで書かれていた。NTTに雇用されているわけではなく、NTTから委託された別会社の社員さんだったようだ。別の株式会社の名称も書いてあった。ただ、その会社が収容されているビルは「NTT」の名前を冠したビルだったけども。NTT資本も入っている会社なのだろうか。

No.2224 〔355文字〕 📖

今回の問題の前に2度同じ現象が発生してその都度修理して頂いたこととか、電話機側でも壁側でもモジュラーケーブルの接続はちゃんと確認したこととか、NTTの故障受付電話(113)で話すのはかなり難しそうに感じる。トラブルの現象をWeb上から800文字まで入力して送信できる仕組みがあったから、かなりスムーズに手続きが進んだのは良かった(NTT側から最初に折り返しの電話があった時点で、もう工事手配する前提だったようだ)。NTTがWebを活用してくれていて良かった。NTTはほとんど競争に晒されていない企業だから、あまり改善のインセンティブが働かないと思っていたのだが。最近は電話(音声通話)自体の利用が減ってきて利益も減少しているから、人件費を削減しようという意図でWebを活用するようになった、ということだろうか。

No.2463 〔592文字〕 📖

6代目のメインPCにする予定の新PCが届いた。今回もEPSON Direct製である。いま使っている5代目メインPCはタワーPCだが、今回はミニタワーPCにした。
20201103193640-nishishi.jpg
今使っている5代目のメインPCは、EPSON Directの購入履歴によると2009年12月半ばに購入していたようだ。11年前である。拡張性を重視したタワーPCだったが、11年間であまり拡張はしなかったので、タワーではなくミニタワーで充分だと判断した。メモリを追加したりBlu-rayドライブを追加したりはしたが、拡張スロットには結局1つも何も挿さないままで終わったことになる。いや、まだサブPCとして使い続けるので終わったとは限らないが。まあ「メインPCとして」は終わる。拡張性の高さを確保しておくこと自体は良いのだが、重たいので、筐体を開けようとするたびに運ぶのに苦労するのだ。私の腕力で容易に持ち運べる重さでないとメンテナンスが億劫になってしまって困る。新PCはミニタワーなので(筐体内部が狭いから)ネジなしで内蔵機器を固定するような便利な仕組みはないが(大きくはないのでその分)重たくはない。とはいえ、ストレージだけはフロントアクセスパネルから出し入れできる筐体なので、ストレージの交換は以前と同様に容易だ。これは外せないとても重要な要素である。まだ開梱はしていない。設置場所をまだ作れていないからだ。

No.2464 〔1058文字〕 📖

私のメインPCのメーカーは、①EPSON(PC-98互換)→②NEC(PC-9821)→③Gateway2000→④DELL→⑤EPSON Directと変遷して来て、今回もEPSON Directを選択して6代目だ。ノートPCは歴代すべてPanasonicのLet's noteで、A77→R2→R5→CS4なので今が4代目。とすると、PC全体としては今回ので10台目なのだった。歴代PCの中で最も長期間使ったのが、今の5代目メインPCで11年間だ。一番短かったのはどれだろうか、と思ったのだが、昔のこと過ぎて覚えていなくて判断できない。なお、数にカウントしていないがMacも1台ある。ただ、これはメインPCの座だったことはないが。CPUがIntel製になる前のMacで、Safariで表示確認するために友人から格安で譲り受けた。ほぼブラウザしか使わなくて、もったいないといえばもったいなかった。今は使っていないが、箱の中にはしまってある。歴代PCの前半は既に処分しているので存在しないが、故障によって買い換えたPCは1つもない。どれも単にスペックが足りなくなったための買い換えだ。4代目メインPCであるDELL製PCを処分してしまったのは今も後悔している。FDDも搭載されたWindows XPマシンだったのだが、それでしか動かない周辺機器とソフトウェアがあるのだ。何を思ったのかいろいろ処分したい気分になってしまって、2015年頃に処分したのだったような気がする。今後はできるだけ捨てないようにしたい。特に今使っている5代目のメインPCはWindows7 PCなのだが、フリーソフトの開発に使ってきた統合開発環境がWindows10では動かないので、このPCが使えなくなると、フリーソフトの開発が一切継続できなくなってしまう。仮想環境でWindows7を動かすことで開発環境を移行することはできるかもしれないが、統合開発環境のアクティベーションが今もできるのかどうか微妙なところ(元々の開発会社が既に買収によって存在しない)なのだ。もっとも、フリーソフトの開発から遠ざかって久しいのだが。C++言語の書き方自体を既にほとんど忘却している。既存のソースを修正することはできるだろうが、新たに1から書くのは学び直しが必要だろう。ただ、C++言語を今さら使う気にはあまりなれないのだが。今はフリーソフトを作るよりもフリーCGIを作る方が楽しい。ただ、モバイルアプリを開発したい気はなくはないのだが。ただ、ネタがない。

No.2492 〔493文字〕 📖

PDFをWord形式に変換したいという質問を時々受ける。Word文書をPDF化するのではなく(それは昔から簡単だ)、PDFとして受け取った書類を編集するためにWordファイルに変換したいという相談だ。この種の相談を時々受けるのであまり知られていないのだろうが、Microsoft Word 2013以降ならPDF形式のファイルも直接読み込めるのだ。PDFをWord文書に変換したいなら、Microsoft WordでそのままPDFを読み込めば良いのである。なお、見積書のような表を含むPDFをExcelファイルに変換したいという需要もあるのだが、残念ながらExcelではPDFを直接読むことはできない。しかし、一旦そのPDFをMicrosoft Wordで読み込んでから文書全体を範囲選択したうえで白紙のExcelシートに貼り付ければ、上手い具合に表構成を維持したままExcelシートに貼り付けられるので便利である。外部の変換サービスを駆使しなくても、実は簡単だ。外部の変換サービスが必要になるのは、元のPDFが紙書類のスキャンでしかない場合のように、OCRが必要になる場合だけだろう。

No.2547 〔247文字〕 📖

Windowsのコマンドプロンプトでverコマンドを実行すると、OSビルド番号は教えてくれるが、Windows10のバージョン番号は教えてくれない。しかし、winverコマンドを実行するとバージョン情報ウインドウが開き、そこではOSビルド番号だけでなくバージョン番号も表示される。もちろん、スタートメニューから「設定」→「システム」→「バージョン情報」をたどっても表示されるが。コマンドを打つ方が早そうな気がする。コマンドプロンプトは、[Windowsキー]+[X]→[C]と打つと起動できる。

No.2552 〔112文字〕 📖

Windows10をキー操作だけでシャットダウンしたい場合は、[Windowsキー]+[X] の後に [U]キーを2回押せば良い。再起動したい場合は、[Windowsキー]+[X] の後に [U]→[R] の順で押せば良い。

No.2577 〔302文字〕 📖

ドメイン取得20年と3日。私のメインサイトで使っている独自ドメイン nishishi.com を取得したのは、どうやら2000年11月15日(水)だったようだ。平成12年。なんと20年(と3日)も経ってしまっていた。当時は年間のドメイン維持費が2万円とかだったような気がする。今は1,800円くらいだったっけ? いくらだろうと契約し続けないわけにはいかないので維持費を把握していない。当時は日本語だけの手続きでドメインを取得させてくれる会社がとても少なかったので、競争がほとんどない価格だったのだろう。そういえば、このドメインを取得するために三井住友VISAでクレジットカードを作ったのだったような気が。

No.2578 〔163文字〕 📖

ドメインが20周年でも、ウェブサイトが20周年というわけではないのだが(23年くらいだ)。しかし、サイト名を「にししふぁくとりー」にしてからは20年なような気もする。独自ドメインを取得した直後にウェブサイトをここに移転したわけではないので、いつが始まりなのかハッキリとは思い出せないが。しかし、あれから20年も経ったのか……。

No.2579 〔136文字〕 📖

過去の記録を探してみたところ、ウェブサイトの公開場所をこの nishishi.com に移行したのは2000年12月06日(水)だった。20年まであと半月くらいあった。それまでの3年弱はBIGLOBEの個人用スペースで運営していた。そのURLは既に消滅していて存在しない。

No.2619 〔324文字〕 📖

Windows10は高速スタートアップ機能がデフォルトで有効なので普段の起動はとても速いのだが、ハードウェア構成を弄りたいときには都合が悪いので、一旦完全にシャットダウンする必要がある。「シャットダウン」ではなく「再起動」を選択すれば高速スタートアップは一時的に無効になる(=完全シャットダウンできる)のだが、電源を切りたいのだから再度起動されたら困る。しかし、いちいち高速スタートアップ機能を無効に設定するのは面倒だ。そんなときには、[Shift]キーを押したまま「再起動」を選択すると良い。すると、Windows側がブルーの画面で「おめーは何がしてえんだ?」と尋ねてくるので、そこから「PCの電源を切る」を選ぶと完全シャットダウンをしてくれる。

No.2754 〔407文字〕 📖

デジタル化で置いてきぼりにされる不安を感じる高齢者について書かれた記事に「高齢者の中にはデジタルと聞くだけで拒否反応を示す人も一定数はいる」と書いてあった。デジタルというとコンピュータのことだけを指すと思われがちだが、そうではない。そろばんもデジタルである。そろばんの珠は、例えば1の珠を1つ動かすと1になるが、少し足りない97.2%だけ珠を動かしたからといって0.972を表すわけではない。1の珠を使って表されるのは0か1のどちらかだけだ。これはデジタルである。アナログは、アナログ時計の連続秒針を思えば分かりやすい(重量計でも速度計でも温度計でも良いが)。秒針が0秒と1秒の間を9割だけ移動したとき、それは0.9秒を表している。9割2分だけ移動したときは0.92秒だ。このような連続的に変化する量のことをアナログという。デジタルとは、中間のない離散的な数値で表される方式のことだ。そろばんの珠もデジタルである。

No.2757 〔378文字〕 📖

2021年の節分は、2月3日ではなく2月2日になるらしい。1897年(明治30年)以来の124年ぶりだとか。節分って2月3日固定なのかと思っていたら春分秋分みたいにズレる年のある日だったのか。その点を考慮しているカレンダー生成プログラムってどれくらいあるだろうか?(^_^;) 春分の日・秋分の日については日付を出す計算式があるのでそれを使えば万年カレンダーが作れるが、節分の計算式は見たことがなかった(というか節分に計算式が必要だと思ったことがなかったので調べようと思ったことがなかったのだが)。計算式だけで算出できるわけではなく、計算結果をテーブルに当てはめないといけないが。この表の計算式もあれば万年カレンダーを実装できるが、西暦2100年以後のことを考慮する必要性はないと考えて良いからあらかじめ持っているテーブルを参照するだけでも不都合はないか。

No.3037 〔203文字〕 📖

[悲報]エコキュートが故障してお湯が出ない……。(´・ω・`) 修理を手配したが、週末は修理予約が詰まっていて月曜日になるとのこと。ええー。表示されているエラー番号からしてタンクから水が漏れている可能性があると指摘されたのだが、いま雨が降っているので目視で確認できない……。orz しかし、漏れているなら放置すると延々と水道代が掛かってしまうので止める必要があるよな……。明日の朝にもう一度確認しなければ。

No.3042 〔226文字〕 📖

今日故障したエコキュートは導入から13年くらい経っているらしい。いや、導入から13年かどうかは分からないが、故障受付担当の人は「製造から13年経っている製品だ」と言っていた。なので、修理部品がない可能性もある、という話だが。この手の製品(=安くはないインフラ設備)を導入するときには、メーカーがどれくらいのスパンで製造を打ち切っているかとか、修理に必要な部品を製造打ち切りから何年間確保しておく方針なのかとか、そういう点も調べた方が良いのかもしれない。

No.3043 〔55文字〕 📖

久しぶりに長い雨が続いている。おかげでエコキュートが水漏れしているのかどうかさっぱり分からぬ。_(:3」∠)_

No.3044 〔434文字〕 📖

昨日から雨が降り続いているので、エコキュートから水漏れしているのかどうかが目視では判断できないのだが、延々と「沸き上げ中」表示が出ているのに「残湯なし」表示が続いていることから、たぶん漏れているのだろうと判断して、沸き上げを停止する設定にしてから、本体のパネルを外して止水栓を捻って水を止めた。すると、本体から聞こえていた「水が流れる音」は止まった。この、本体から聞こえてくる「水が流れる音」が果たして漏水の音なのか、それとも普段から聞こえる音なのかは(普段の状態を確認したことがないので)分からないのだが。まあ、漏水していたら水道代が数万円に跳ね上がるという話も聞くので、(どうせ今お湯は出ないのだし)止めておく方が無難だろう。……ということを昨夜の内に気付いて実践できたら良かったのだが、ほぼ丸1日放置してしまった。(昨夜は、今日もし雨が降っていなかったら目視で確認できるだろう、という期待があったので先送りしてしまったのだった。マニュアルも熟読はしなかったし。)

No.3045 〔568文字〕 📖

エコキュートの配管から丸1日ほど水が漏れていたら総量はどれくらいになるのだろうか。もし1リットルの水を3秒で出せるとすると(蛇口からはそんなに速くは出ないがエコキュートの配管は太そうだったから)、1日は1,440分なので28,800リットル? だいたい水道代って1リットル0.2円くらいだと思うので、そうだとしたら5,760円くらいだろうか。まあ、1秒で何リットルの水が漏れているのかが分からないので推測しようがないけども。毎秒1リットルだと17,280円くらいだが、さすがに毎秒1リットルを超える速度はないのではないかと思いたい。ただ、水の音は結構大きくしていたので(あれが普段から聞こえる正常な音ではないのだとしたら)ちょろちょろ漏れるレベルではない。あと、丸1日無駄に沸き上げが行われていたので電気代もそこそこかかっていそうだ。ただ、エコキュートは電力で直接水を温めるわけではないので、そんなにすごいことにはならないと思うのだが。これは参考情報が少なすぎて推測できないな……。いや、もうちょっと頑張って調べたら何か出てくるかもしれないが、推測に推測を重ねて数値を出しても意味がないので、調べていない。そもそももう済んだことだし。とりあえず丸1日だけで済んだので良しとしよう。修理は2日後なので、残り2日分の無駄は省けたわけだから。

No.3050 〔177文字〕 📖

国税庁がブラウザアドオンをChromeウェブストアで公開する時代。e-Tax AP これを入れないと確定申告の電子申告ができないようだ。これだけを入れてもダメで、他にも要求されるソフトを入れる必要があるのだが。このアドオンは、Chromium系ブラウザで、ローカルPCに接続されたICカードリーダを扱ってマイナンバーカードを読み取るためのアドオンっぽい。

No.3051 〔112文字〕 📖

これまでほぼInternet Explorerだけが対応ブラウザだった電子申告に、ようやくChromeが使えるように。
20210125011846-nishishi.png
ただ、Chromeに余計なアドオンを入れたくないので、(Chromium版の)Edgeを使う。

No.3052 〔401文字〕 📖

国税庁が公開していて今年からは電子申告に必須になったっぽいブラウザアドオンe-Tax APのユーザレビューを何気なく表示してみたら、文句がすごくてちょっと笑った。たしかに、IEを使っていたとき(=IEだけが使えていたとき)は、国税庁サイトからダウンロードできる事前準備ソフトウェアさえインストールすれば(IE上で動作する拡張機能もそこでインストールされたので)あとはウェブ上ですべて完結したのだが、ブラウザアドオンが必要になった今年は手順が増えて煩雑にはなっている。モダンなブラウザのセキュリティを考えると仕方がないのだろう。いっそのこと、国税庁自身がChromiumベースの電子申告専用ブラウザを開発して配布したら良いのでは。(笑) Chromiumベースならブラウザを1から作る必要はないわけだし。それなら必要なアドオンは最初から搭載した状態で配布できる(というかアドオンにする必要もない)だろう。

No.3053 〔512文字〕 📖

先のレビューを読んでいると、「インストールしたのに何も出てこない!」と叫んでいる人も居た。ブラウザアドオンの他にもローカルアプリっぽいソフトを2本インストールさせられるので、まるで確定申告専用ソフトなるものがPCに入るように誤解したのだろう。インストールしたのはすべて「ブラウザ上から電子申告するための付加機能」みたいなものであって、実際の電子申告はすべてブラウザ上から行うのだ。なので、スタートメニューやデスクトップに何かが出てくるわけではなく(※公的個人認証サービスというフォルダ名で細かな設定をするソフトは入るのだが)、次にしないといけないことは国税庁サイトの確定申告ページから手続きを始めることである。事前準備ソフトのインストーラの最後の画面では、一応はそのウェブページへ誘導されてはいるのだが、よくよく見ると、この説明では「単に案内Webを読ませようとしているだけ」と感じられてしまっても無理はない気もする。
20210125014350-nishishi.png
これまで何度も確定申告をしてきた人ならここは迷いようのないところだが、今年に始めたばかりの人だと迷うかも知れない。ここは「表示しますか?」ではなく、強制的に表示させた方が迷う人を減らせただろう。

No.3056 〔158文字〕 📖

担当者さんから電話があって、エコキュートの確認に来てくれる時刻は決まった。その場で修理できる程度の状況だったら良いのだが。3日前の時点ではエラー番号は1つだけだったのだが、今は3つに増えている。E-20、E-22はエラー番号一覧表に記載があるのだが、P-17という一覧表に記載のないエラーも出ているのだがががが……。

No.3057 〔133文字〕 📖

良かった。エコキュートの修理は今日だけで完遂されそうな感じだ。場合によっては部品の調達に時間が掛かるとかそういう可能性も危惧していたが、どうやら既に持ってきている部品で修理完了できるっぽい。修理費用はだいたい1万5千円くらいだとのこと。予想より安かった。ありがたい。

No.3058 〔469文字〕 📖

エコキュートが直った。めでたい。部品が腐食したか何かで穴が開いて、そこから水がこぼれていて、内部の配線に悪影響を及ぼしていたことが主な原因らしい。実際の部品を見せてもらって説明を受けた。穴の大きさからして、漏れていたのは確かだが、漏れる速度はそれほど速くはなさそうな感じではあった。念のために止水栓を捻って水を止めておいたが、そうしなくても大きな問題はなかったのかもしれない。もちろん、止めておくことに越したことはないのでそれ自体は良いのだが。だいたい3年前・4年前くらいにも何度か修理しているエコキュートなのだが、「何度も修理に来ているから」ということで出張料等を値引きしてくれる親切な作業員さんだった。おかげで、たぶん部品代だけの負担で済んだっぽい。もし次に丸ごと買い換えることがあっても、三菱電機のエコキュートにしようと思えるような良い人だった。(笑) この手の家電は委託を受けた地元の提携電気店から作業員さんが来るのかなと思ったらそうではなく、三菱電機(の子会社)から来た人だったようだ。たぶん。全作業時間は2時間半くらいだった。

No.3129 〔738文字〕 📖

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

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.3140 〔314文字〕 📖

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

No.3146 〔98文字〕 📖

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

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.3218 〔399文字〕 📖

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

No.3238 〔497文字〕 📖

昨年に購入した「一太郎2020 プラチナ版」には、ジャストシステム製のPDF編集ツールが3種類おまけに付いてくるのだが、このうち「JUST PDF4 データ変換」は、(PDFは関係なく)任意の画像ファイルからOCRでテキスト化する機能もあるのだと知って驚いた。
20210221181154-nishishi.jpg
さっき、何気なくタブレットでキャプチャした電子書籍の1ページを取り込んでみてテキスト化を試してみた。「どうせ『扱えません』的なエラーが出るのだろうな」と予想していたのだが、すんなりテキスト化できて驚いた。下記はAndroid端末上で、電子書籍の罫線(表組み)ページをキャプチャした画像を「JUST PDF4 データ変換」に取り込んだところ。
20210221181154-nishishi.png
これをMicrosoft Wordの.docx形式と一太郎の.jtd形式に変換してみたのが下図だ。表も問題ないし、テキストの日本語もほぼ正しい(1点だけ読点が「x」になっているが)。
20210221181143-nishishi.png 20210221182924-nishishi.png
こんなに有用なオマケだったとは今まで気付かなかった。「JUST PDF4」という名称が少々損をしているのではないか。なお、これは単品でも販売されているソフトである。

No.3239 〔381文字〕 📖

(承前) どの部分をOCRで文字として認識しているのかを表示するモードもあった。認識はほぼ正しい(リンゴやミカンの絵が「OQQ」と認識されている程度)が、必要に応じて認識範囲を手動で修正することもできるようだ。認識結果のテキストを直接編集することもできて、ここで編集しておけば編集結果を最終データとして出力できるっぽい。なかなか便利だ。無駄な改行もここで取り除いておけば楽かもしれない。
202102211927581-nishishi.png 20210221192758-nishishi.png 20210221193245-nishishi.png
縦書き・横書きの混在も問題なかった。2段組レイアウトでもちゃんと正しい順序で認識していることにちょっと驚いた(2枚目の画像)。罫線もないのに。テキスト認識は、フォントによって、カタカナの「ロ」が四角記号になったり、小さい「っ」や「ャ」が大きな「つ」や「ヤ」だと認識されている箇所はあったが。まあ、その辺はOCRならありがちなので仕方ないだろう。

No.4081 〔857文字〕 📖

春分の日、秋分の日や、夏至・冬至は、日付が決まっているわけではなく毎年微妙に異なるので、カレンダー生成プログラムを作るようなときには計算式で日付を求める必要がある。それぞれ以下の通りだ。
●春分:int( 20.8431 + 0.242194 * ( $year - 1980 ) - int( ( $year - 1980 ) / 4 ) )
●秋分:int( 23.2488 + 0.242194 * ( $year - 1980 ) - int( ( $year - 1980 ) / 4 ) )
●夏至:int( 22.2747 + 0.24162603 * ( $year - 1900 ) - int( ( $year - 1900 ) / 4 ) )
●冬至:int( 22.6587 + 0.24274049 * ( $year - 1900 ) - int( ( $year - 1900 ) / 4 ) )
未来永劫使えるわけではなく、夏至・冬至に関しては2099年まで有効な計算式らしい。なぜこの計算式で計算できるのかは理解していない。
なお、$yearは西暦4桁の数値を入れる変数で、intは小数点以下を切り捨てて整数化する関数を指している。

節分も2月3日固定ではなく年によって変化するという驚きの事実を昨年末に初めて知った。今年は2月2日が節分だった。124年ぶりのことらしい。そんなに間が空くのなら、今後しばらくは2月3日固定で良いのかな……、と思ったらそうでもなく、2025年、2029年、2033年など閏年の翌年が2月2日になるパターンがしばらく続くらしい。そんなわけで、節分もカレンダーに表示したければ以下の計算式を使う必要があるようだ。
●節分:int( 4.8693 + 0.242713 * ( $year - 1901 ) - int( ( $year - 1901 ) / 4 ) ) - 1
こちらは最後に1を引かないといけない点に注意が要る。

No.4092 〔1035文字〕 📖

日付を入力するだけで「その日が祝日かどうか」を判定する処理はそんなに難しくないだろうと高をくくっていたのだが、「振替休日」と「国民の休日」という2種類の臨時休日の判定が意外と複雑なので、単に日付を指定するだけではその日が祝日なのかどうかは分からないことが分かった。少なくとも「調べたい日の直前の日曜日」から「調べたい日の翌日」までの毎日が休日なのか平日なのかを調べないと特定できない。「振替休日」は、祝日が日曜日と重なった場合に「次の平日」が休日になる制度なので、ほとんどの振替休日は月曜日になるのだが、5月の連休時だけは祝日が連続するので、火曜日や水曜日が振替休日になる可能性がある。なので、祝日リストを持っているだけではダメで、「調べたい日の直前の日曜日」から当日までの状況を調べてからでないと「今日が休日なのか平日なのか」が特定できない。「国民の休日」は祝日と祝日に挟まれた1日が休日になる規則だが、祝日と祝日に挟まれた1日が日曜日の場合には特に何もないし、最初の祝日が日曜日の場合には自分自身(当日)は振替休日になるだけであって国民の休日ではない。なので、調べたい日の前日と翌日が祝日かどうかを判定してから、その日が日曜日または振替休日ではないことを確認する必要がある。昔はこの規則によって5月の連休が構成されていたのだが、今では5月の連休は本当に「3連続の祝日」になっているのでこの規則は使われていない。しかし、数年に1回だけ、この規則によって9月にシルバーウィークができる(次回は2026年だ)。なお、今のところの祝日規則上では発生しなさそうだが、『振替休日と祝日に挟まれた平日1日』が「国民の休日」になるのかどうかがよく分からない。将来的にそういう状況が発生するよう祝日が新設されたり移動されたりしたら、またカレンダー生成プログラム製作者が苦労しそうである。いや、苦労するかどうかは分からないが、少なくともプログラムはアップデートする必要があるだろう。昨年と今年には臨時に祝日が移動する法律ができて一時的に祝日が変化したが、このような臨時移動に対応できるカレンダープログラムはそうそうない気がする。祝日リストを編集できるプログラムはあるだろうが、「ある特定の年だけは異なる祝日リストを使う」というような状況を事前に想定しているプログラムはさすがになかったのではないか。そういうのを今作っているのだが、なかなか手間が掛かる。祝日規則はシンプルにして頂きたい。

No.4189 〔639文字〕 📖

Amazonの荷物をクロネコが配送する際には、EAZYで指定しておくと指定位置に置き配してくれるのだが、指定位置の選択肢に「郵便受け」がない。そもそも「荷物が小さければ○○に、大きければ◇◇に置いてくれ」的な条件指定はできない。Amazonは、郵便受けに入るサイズの荷物(しかも価格も安い物品)でも何故か宅急便指定で送ってくることがあって、そういう小さな物体は扉の前とかに置かれるよりも普通の郵便と同じように郵便受けに入れてくれる方がありがたい。配送担当者にとってもその方が楽で良いだろう。というわけで、インターホンの下に貼り付けておく葉書サイズの掲示を作ってみた。それが下図である。(右上と右下の絵はいらすとやから拝借したもの。)
20210627155453-nishishi.png
先日注文した荷物が(Amazon上では日付指定やお急ぎ便ではなく「通常配送」を指定したのに)宅急便で発送されてしまった。しかし、中身は小物1つなのでおそらく封筒サイズの小さな梱包で届くだろうと予想できた。そこで、上図を葉書サイズの紙に印刷してPPクリアシートに入れてからインターホンの下に貼っておいた。すると、クロネコ配達員さんは意図通り(チャイムは鳴らさずに)郵便受けに入れておいてくれた。ありがたい。ぱっと見て意図を把握してもらえるかどうかを心配していたのだが大丈夫だったようだ。(少なくとも今日の配送担当者は、だが。) Amazonもヨドバシのように配送方法として明示的に「メール便」を指定できる仕様になってくれると良いのだが。

No.4200 〔646文字〕 📖

iOS用アプリを作って公開するためには、App Storeに登録する以外にない。App Storeに自作アプリを登録できるようにするには、Appleに年額11,800円(米国だと99ドル)の年間登録料を支払い続ける必要があるので、気軽にちょっと登録してみようかなとは思いにくい。年額ではなく最初の1度限りの費用だったら構わないのだが。Google Play StoreもMicrosoft Storeも「1度限りの支払いで永久登録」な仕組みだ。しかも、Googleは25ドル(2,800円弱)、Microsoftは19ドル(2,100円程度)である。法人登録だともう少し高いが。なお、いま初めて調べたのだが、AndroidアプリでもAmazon App Storeだったら費用ゼロなようだ。Appleだけがめちゃくちゃ強気の料金形態なのな。桁も違うし回数も違う。iOS向けに無料アプリだけを公開している人は、毎年11,800円の赤字なのだ。これまでならAmazon App Storeにアプリを登録しようと考える人はそんなに居なかっただろうけども、Amazon App Storeに登録したAndroidアプリがそのままWindows11でも動作する(可能性がある)となると、今後の登録数は大きく増加するのかもしれない。Microsoftは「Windows11上で動作するAndroidアプリ用ストア」はAmazon以外にも増やすっぽいことを言っているようだけども、他にどこがあるのだろうか。

No.4644 〔662文字〕 📖

Twitterのトレンドに「Windows11」の話題が出ていたので、Win11リリース関連のツイートを眺めていたら、「Win10スタートメニューの右側は全然使わないよね」的な意見があって、それに賛同が多くて驚いた。あの領域は端をドラッグすれば領域を拡張できるのだが、そこに自分の好きなようにアプリを配置しておけば、[Windows]キーを押すだけで開くランチャーとしてすごく便利なのだが。デスクトップにアイコンを並べていると、ウインドウをたくさん開いているときにはデスクトップへアクセスするのが面倒だが(いや、デスクトップにはタスクバーの右端の端をクリックすれば開いている全ウインドウを一気に最小化できるからアクセス自体は簡単なのだが、その方法でデスクトップを表示すると、最小化されたウインドウを元に戻すのが面倒くさい)、この方法ならスタートメニューを表示するだけでアクセスできるので、ランチャー(=アプリを簡単に起動できるアプリ)としてとても楽に使える。
20210901144448-nishishi.jpg
Windows10でのMicrosoftの失敗があるとすれば(たくさんあるが)、スタートメニューの右側の領域を有効活用する方法をユーザに分かりやすく提示できなかったことだろう。デフォルト状態でもっと右側に余った空間を見せておいて「ここに好きなようにアプリをピン留めできますよ」と示しておく方が良かったのではないか。なお、この話は2016年にブログ記事「Windows10のスタートメニューは面積を縦横に大きく広げてアプリを一望できるようにすると便利」にも書いた。

No.5807 〔806文字〕 📖

Newsweekの定期購読継続の案内封書が届いたのだが、継続料金を見て衝撃を受けた。3年150冊で 63,900円。ろくまんえん!?Σ( ̄ロ ̄lll) なんでや……。1冊あたり426円もする。定価とほとんど変わらない。前回(3年前)は3年150冊で 43,200円(1冊あたり288円)だったので2万円も高くなっているではないか。この3年間で本誌の定価は高くなってはいるが、せいせい数十円くらいである。140円弱も高くなるほどの差はない。書面をよくよく見ると、3年前には印字されていた「ご継続特別割引適用」の文字がない。継続購読の特典がなくなったのだろうか。
202202041752071-nishishi.jpg 20220204175207-nishishi.jpg
……と思ったのでNewsweek読者センターにWebから問い合わせてみたところ、速攻で返事が返ってきた。曰く『「継続特別割引」は、2020年で終了させていただきました。長年ご契約いただいているお客様には心苦しい限りでございますが、購読をご検討いただけましたら幸いでございます。』とのことだった。┌(:3」└)┐ ええー。割引率を下げるとかではなくて、いきなり全廃なのか。世界の出来事を知るのにNewsweekは読みたいのだが、毎週426円出して読むかというとなかなか微妙なところである。紙版をやめて電子版にすると42%OFFで1冊あたり280円(3年150冊で42,000円)で済むので、そろそろ電子版にすべきか。電子版だと10インチ超の画面がないとおそらく読みづらいので、大型端末を手に入れねばならないのだが(PCのディスプレイは充分大きいが、食事中に読みたいのだ)。しかし、Androidタブレットだと10インチクラスでも2万円弱で買えるので、(直近3年間分の購読費用だけと比較しても)紙を定期購読するよりは安く済みそうだ(端末が3年故障せずに持てばの話だが)。うーむ。紙の定期購読は解約かな……。読みやすいのは紙なのだがなあ。

No.5884 〔1065文字〕 📖

2000年代から所有している.comドメインを1つ破棄する計画を数年前から持っている。ただ、いきなりドメインを破棄すると(それなりに長く所有しているドメインな上にそこそこのページ数があったサイトなので)SEO目的で広告会社等に再取得されてしまう可能性があるだろうから、SEO的な価値を充分に下げてから破棄する計画を立てた。まずウェブサイトは2年前くらいに完全閉鎖して、他サイトに移した一部のコンテンツだけは個別にリダイレクトさせ、残りは(移したコンテンツ群を統括する他サイトのHOMEへ)一括リダイレクトするようにした。その状態で1年間放置したので、検索結果には完全に出てこなくなった。そこで1年ちょっと前からはリダイレクト処理も終了させ、アクセスしてもサイト全体で 410 Gone のエラーを返すだけの状態にしてある。
20220213123327-nishishi.png
ここまですればSEO的な価値はゼロに等しいくらいに下がっているのではないかと期待している。で、ドメインの期限がそろそろなので、このまま予定通りに権利を放棄しよう……と思っていたのだが、自サイトの古いブログ記事からわりとたくさんリンクしていたことに気付いた。他所のサイトからリンクされている場合にはどうしようもないが、せめて自サイトからのリンクくらいは消しておいた方が、よりドメインの価値を下げられて望ましいと思うので、ちょくちょく削除作業を進めていたのだが、予想以上に多くて手間が掛かっている。……というわけで、ドメインの破棄は1年先送りして、もう1年だけ所有しておくことにした。
202202131230261-nishishi.png 20220213123026-nishishi.png
そのドメインの維持に使っているムームードメインからは、「失効したドメインの復旧には金がかかるよ」とか「同じドメインを取り戻すことは非常に困難よ」という警告が何度かメールで届いていた。ドメインの失効後には、たいてい元の所有者に対する救済措置的な期間があるが、期間や費用はドメインによって異なる。.comドメインの場合は30日間の猶予の後に誰でも再取得可能な状態になるようだ。あと30日間のうちに自サイトからすべてのリンクを削除できる可能性もなくはないのだが、今月はちょっと仕事で忙しいので、まあ良いだろう。破棄すると決めているドメインに、さらに1年分の維持費(1,728円)をかけるのもどうかと思わなくもないのだが、失効直後に広告サイトに変貌しても嫌な気分になるだろうから、精神安定のための保険と考えておく。完全閉鎖から2年も経っているので、既にその心配はないとは思うのだけども。まあ、念には念を入れて。

No.6167 〔1286文字〕 📖

ドメインの権利を破棄すると、その後は誰でも再取得可能な状態になる。ので、昔々に運営されていた人気サイトが、今では全く別の怪しげなサイト(日本語ではないこともよくある)に変貌しているケースを時々見かける。それらは『昔のサイトとは全く異なるサイト』になっているから、まだ「ああ、このドメインは一度破棄されて、第三者に取得されたのだな」と推測できるのだが、元々あったサイト(ドメイン破棄前のサイト)のデザインをそのまま流用して全く別のサイトを作られてしまったら(もしくは勝手にコンテンツを引き継いで偽サイトが運営されてしまったら)元の運営者へのダメージが比較にならないほど大きくなりそうな気がする。例えば、元のサイトに「運営者のプロフィールページ」があったとして、そこを元の状態に復活させた上で、デザインも元のサイトのままで、コンテンツだけアダルトアフィリエイトサイトとかに変えて運営されるとか。ドメインを再取得しても(サーバ契約は別なので)元のコンテンツが手に入れられるわけではないが、破棄されてからあまり期間が経っていなければGoogleのキャッシュとかに残っているだろうからそこからコピーできるだろう。そこまで手の込んだ方法ではないが、ブログベースのサイトでそういう感じのケースを見かけた。とあるブログサイトで、ブログツールの公式テンプレートそのままのデザインを使ってブログが運営されていた(運営者はラノベ作家さん)のだが、ずいぶん前にドメインを破棄されたようだった。で、その後に第三者が取得して、同じテンプレートを使って全く別のブログの運営を始めたようだった。全部推測なのだが、そう思ったのはWayback Machineで確認すると、数年間の無更新状態を経て1年ちょっとくらい一切キャッシュのないブランク期間があったからだ。ドメインのWHOISも見れば良かったが、そこまでは確認しなかった(そのときはそこまで深く興味は持たなかったので)。内容は別に特に悪質なものではなかったのだが、最初に見たときは「へえ、あの作家さん、こんなことも言うのか」と意外に感じた。で、よくよく見ると運営者名が別人になっていたので、破棄ドメインを再取得してデザインを同じにして運営しているのか、と気がついた。まあ、作家さん本人が別人を装って運営している可能性がないとは言えないが。というか、そういう疑問を閲覧者に感じさせる時点で、既に元の運営者にダメージがありそうな気がする。長く運営してきたサイトを閉鎖してドメインを破棄しようとするときには、1年間くらいは「閉鎖しました」的なメッセージだけを残しておいて、しっかりそれを方々にキャッシュさせておいて、サーバを解約した後も2~3年くらいはドメインだけは権利を保持して「どこにも接続できないドメイン」みたいな感じにしておいた方が良さそうだ。そうしておけば、破棄ドメインが再取得されて、しかも同じデザインで別サイトを運営されてしまったとしても、「別人が運営している」と気付いてくれる人の割合を増やせそうな気がする。一番良いのは破棄しないことだが。

No.6282 〔304文字〕 📖

最後に書いてから15年以上もモバイル非対応のまま放置していたコミケレポートコーナーを、スマートフォンでも閲覧可能なモバイル対応にした。文字コードもSHIFT-JISだったのをUTF-8に変えた。コンテンツに変わりはないので、何かレポートが増えたわけではないし、写真のサイズも昔のまま(極小サイズ)なのだが。20年の歳月を経て閉鎖されてしまったお台場ヴィーナスフォートでのオフ会の様子がコミケ66 レポートにある。2004年の夏コミだ。ヴィーナスフォートへ行ったのはこの1回だけだった。ほとんど記憶にはなかったが、自分で書いたレポートを読んで「そういえばそんなこともあったな」とおぼろげに思い出した。
20220408220051-nishishi.jpg

No.6283 〔473文字〕 📖

「中高年」というのは大辞林によると45歳以上65歳程度の人を指すらしく、明鏡国語辞典によると40代~60代の人を指すらしい。20数年くらい前、ようやくインターネットが普及し始めた頃に、たぶん「中高年はデジタルが苦手」みたいに言われ始めたのが最初で、その言葉だけが今も言われ続けているのだろうか? 当時の20代が今は40代なので、少なくとも今の中年はもはやデジタル機器苦手世代ではない。……と私も最初はそう思ったのだが、そうは言ってもそれらが苦手な人も居るには居るわけで、それがどれくらいの割合なのかが気になる。同年代でそれらを苦手だと言っていそうな知り合いに心当たりはまったくないが、それは単に私の知り合いに偏りがあるだけだろうしな……。リンク先で『「デジタルに苦手な中高年40代」って雑誌の人が言ってて驚いた』と語られていたのでここでも「デジタル」と書いたが、PCやタブレットのような情報機器を指して「デジタル」と言われると、「そろばんもデジタルだ」と言いたくなるので、個人的にはあまりその表現は使わない。なお、私はそろばんは全然得意ではない。

No.6531 〔743文字〕 📖

んぎゃあー。AppleがiPod touchの販売を在庫限りで終わるとアナウンスしたらしい。iPod touchは現在の第7世代で終わってしまうのか……。iPod touchはiPhoneと同じiOSが動作しているので、事実上は「電話機能とGPS機能だけを省いたiPhone」みたいな感じだったのだが、記事によるとApple的にはあくまでも「携帯音楽プレーヤー」だったのだな……。今、物理的なイヤホン端子がある携帯端末は少ないのではないかと思うのだが、iPod touchの筐体は初代から変わらないので3.5mmイヤホン端子もある。イヤホン端子があるとヘッドホンを有線で接続できるので、聴力検査アプリを使うのにも重宝していたのだが……。あと、ディスプレイの端がカーブしておらず端まで四角く表示される点も私の中では評価が高い。うーむ、終わってしまうのか、iPod touch……。まあ、いま使っている第7世代iPod touchがいきなり使えなくなるわけではないので、まだしばらくは使えるけども。「次はiPhoneを買えば良いだけでは」と思われるかもしれないが、iPod touchは2万円台から買えるので、安価なiOS端末としても良かったのだ。Appleはまさにその「安い端末」をリリースするのが嫌なのかも知れないけども。「じゃあAndroidにすれば?」と思われるかも知れないが、そうではなく、私の職業ではiOSもAndroid OSも(動作確認のために)両方使う必要があるので、常に「何らかのiOS端末」と「何らかのAndroid端末」を確保しておく必要がある。なので、安価に調達できるiOS端末であるiPod touchはありがたかったのだ。Appleデバイスはたいてい高いので。

No.6541 〔626文字〕 📖

うちのサイト内には要所要所にSNS投稿用ボタン等を配置している。フリーCGI等の配布ページなら上部に、Tips記事やブログなら本文の下に。長年これらは各SNSの公式サイトで提供されているHTMLソースをそのまま書いて表示していたのだが、それらを使うのをすべてやめて自前のスクリプトに変えてみた。各SNS等が提供している公式ボタンだと、それぞれのスクリプトを読み込まなければならないので無駄な通信が増えてしまう点が以前からちょっと気になってはいた。……のだが、差し替えるのが面倒だったので放置していた。しかし、つい最近、Facebook用の連携ボタンが機能していないことに気付いた(ボタンを押してもエラーが出るだけで共有できない状態だった)ので、一念発起して全部を自前のスクリプトに変えた。無駄に公式スクリプトを読みにいかなくなったので、通信量も減り、読み込み速度も向上して望ましい形になった気がする。アイコンで表示しようかとも思ったのだが、アイコンを用意するのが面倒だったのでテキストラベルだけにした。アイコンだけだと「そのページの情報を投稿するためのボタン」なのか「そのSNSの当人ページに移動するためのボタン」なのか判別しにくいので、何をするボタンなのかを言葉で示す方が分かりやすい気もする。いや、後付けの理由だが。ついでに、そのページのタイトルとURLをクリップボードにコピーするだけのボタンも用意してみた。これが一番便利かも知れない。
20220511235821-nishishi.png

No.6556 〔561文字〕 📖

TIPSコーナーの記事等で使ってきたシンタックスハイライター(Syntax Highlighter/ソースを色分け表示してくれるスクリプト)が古すぎて、もはや最近の書き方に対応していない。何か新しいスクリプトを使う方が良いだろうな……と思っていろいろ調べたところ、Prism.jsが良さそうなので、これを使ってみることにした。TIPSコーナーの記事を書き換えるのは大変なのでまだ何もしていないが、さっき書いたブログ記事「SNSシェアボタン等を自前スクリプトで作る方法」内で使ってみた。私は淡い色が好きなので、これまでソースもそんな感じで掲載してきたのだが、ソース部分はむしろ明確に本文と分離して見えるように、暗色スタイルで掲載する方が分かりやすい気が最近はしている。ので、Prism.js公式で提供されている「Tomorrow Night」というダークテーマを適用してみた。使い続けるかどうかは分からないが、しばらくはこれで行ってみる。Prism.js自体はとても軽量なスクリプトで、CSS+JavaScriptソース全部でも21KB程度しかない。とはいえ、ソースを掲載しないページで読み込むのは無駄なので、Prism.jsを必要とするページでだけ動的に読み込まれるようにしてみた。その辺の話も今度ブログに書いておきたい。

No.7892 〔187文字〕 📖

Google Pixel 6a を手に入れた! なんとなくぼんやり予想していたよりは大きく感じる。あと、予想よりもずっしり重量がある感じもする。iPod touchと比較するとずいぶん違う(当たり前だが)。スマートフォンとしては別に重たいわけではないだろうとは思うけども。カタログ値で176gなので。まだ電源は入れていない。Google直販で53,900円だった。
20221102202020-nishishi.jpg

No.7904 〔836文字〕 📖

メインPCに増設するメモリ16GBを手に入れた。今は16GBでも6千円で買えるのか(台湾製)。ただ、昨今の円安でそのうち値上がるかもしれないが。
20221103205548-nishishi.jpg
今使っているメインPCは2年前に買った EPSON Direct製のBTO PCなのだが、製品構成の段階でメモリを増やすとずいぶん割高なので(もう記憶にはないが16GB追加するだけで数万円くらい高くなる感じだったような気がする)、とりあえず初期構成としては16GBで購入した。必要なら後で自力で足せば良いので。で、別に動画編集とかするわけでもないので、16GBでもなんとかなっていたので今までそのままで来た(仮想環境上で別のOSを起動して使う場合には、少々厳しいので他のソフトをできるだけ終了させた上で使うような工夫は必要だったけども)。……のだが、さすがにOSのアップデートを数回経てOS自体がメモリを食うようになったのか、昨年にメインディスプレイの面積が広大になった影響で複数のソフトをよりたくさん併用するようになったためか分からないが、平時の使用でもメモリの占有率がそこそこ上がるようになってきてしまった。下図では77%使っている(※OSの起動直後ならだいたい35%くらいだが)。
20221103205630-nishishi.png
調べると、8GBのメモリ×2本の計16GBでも6千円で買えるので、それなら追加すれば良いか……と思って購入した(Amazonのタイムセールでちょっと安かった)。これを内蔵させれば合計32GBになるので、当面は充分だろう。まだ開封していない。初期不良がなければ良いのだが。メモリを増設するにはPC筐体を開けないといけないが、ただ開けるだけでは済まないかも知れず(ストレージ機器をフロントパネルから出し入れできるようにするために内蔵されているパーツ自体をちょっと動かさないとマザーボード上のメモリの空きスロットにアクセスできない可能性があるので)念のためには、ある程度まとまった作業時間を確保してから取りかかる必要がある。

No.8047 〔49文字〕 📖

新しいSIMが届いたので、Google Pixel 6a を電話として使えるようにした。
20221102202020-nishishi.jpg

No.8186 〔398文字〕 📖

クロネコの代金を「にゃんPay」で払ってみた。便利だな……。チャージ残高0円の状態で「ちょうどチャージ」という自動チャージ機能を使うことで、事実上は『クロネコの代金を銀行口座からの自動引き落としで払う』ような感じで使える。現金を用意しておく必要もなく、電子マネーのチャージ残高を把握しておく必要もなく支払えるので便利だ。(紐付けてある銀行口座の方に残高がなかったらダメだが。)しかも、代金は12%引きである。
202212161809531-nishishi.png 20221216180953-nishishi.png
集荷に来たクロネコドライバーさんに、こちらのスマートフォン上に表示されたコードを見せてスキャンしてもらうと(バーコードの方を読まれたのかQRコードの方を読まれたのか分からなかったが)、支払いが完了した。2~3秒後くらいに、こちらの画面にも金額が出た(上図1枚目)。履歴を見ると、紐付けてある銀行口座から代金分だけがぴったり引き落とされているのが分かる(上図2枚目)。

No.8463 〔526文字〕 📖,🏥

朝から眼科へ行ってきた。慢性的な結膜炎ですね、とのこと。目が乾くのとか、まぶたがピクピク痙攣する症状についてはそのため。目薬をもらった。眼底には一切何も問題がないとのことで、黄斑変性とかの兆候もないという話なのでそこは良かった。緑内障の兆候とかもない。要するに結膜炎だけということだった。視力も維持できていて、概ね1.5ありますね、という話だった。右目だけで真っ直ぐな線を見たときに、視野の右下あたりでほんの少しだけ歪んで見えるのが何故なのかは分からないままだが、(本当に端だし、日常生活には微塵も支障ないのだが、何か病気の兆候だったら放置するわけにはいかないので検査してもらうべく眼科へ行ったわけだが)検査結果としては問題ないとの結果だったので、とりあえず安心である。
処方目薬一覧
目薬
目薬は3種類。ドライアイ改善用の涙液保持目薬はヒアルロン酸なのか。10年前の症状のときに(別の眼科で)処方された薬とは、フルメトロン点眼液だけは共通している。ブログに書いておくと後から振り返って比較しやすくて便利だな……。
症状とは全く関係ないが、視力はさすがに多少は低下しているのではないかと思っていたのだが、ランドルト環を見る検査で 1.5 を維持できていたことに驚いた。

No.8764 〔989文字〕 📖,🏥

長年、春秋の花粉の季節に欠かせなかった薬が、第一三共のプレコール持続性鼻炎カプセルLなのだが、製造終了で販売も終了されていて驚いた……! プレコールというと一般的には風邪薬だと認識されていると思うのだが、それとは別に緑色のパッケージで鼻炎に特化した「プレコール持続性鼻炎カプセル」という薬が長年販売されていて、これが私の花粉の症状を極めて良く抑えてくれるので重宝していたのだが。
プレコール持続性鼻炎カプセルL製造終了 有効成分
それがなんで製造終了やねん!? と思ってググったら、消費者庁のリコール情報サイトに「無水カフェインの溶出性試験結果で製造販売承認書の規格上限を逸脱したため」という理由で回収されていると情報が出ていた。これが原因で製造自体を終わってしまったのだろうか? 58万個を自主回収という新聞記事もあった。第一三共Webの商品ページに掲載されていた自主回収のお知らせによると、昨年の6月以降のすべての製品が対象だとか。ただ、先の消費者庁のWebに書いてある情報によると、有効成分の体内への吸収がわずかに速くなる可能性が考えられますが、含量は規格内であることから、有効性または安全性へ影響する可能性は極めて低く、重篤な健康被害が発生する恐れはないと考えております。とのことなので、別に大丈夫っぽいけども。とりあえず、備蓄が尽きたら今後は他の薬を検討せねばならぬ……。成分が似ている薬があれば良いのだけど。

……と思って探したら、Amazonブランドのビスティー鼻炎カプセルLという薬が、完璧に成分も分量も同一の薬で思わず笑ってしまった。ええんか、これは。いや、この状況ではありがたいけども。┌(:3」└)┐ さらに探すと、小林薬品工業のヒストミン鼻炎カプセルLPという薬も、成分と分量が同一だった。塩酸プソイドエフェドリンを使う場合はこういう構成しかあり得ないのだろうか? というか、カプセルの色がAmazonのと同じなのだが、AmazonのはここのOEM製品なのだろうか? ……と思ったが、アリナミン製薬のベンザ鼻炎薬αは塩酸プソイドエフェドリンを使っているが構成が微妙に異なる。グリチルリチン酸の代わりにトラネキサム酸が含まれていた。だから、鼻炎だけでなく喉の痛みにも効くようだ。私の場合、喉が痛くなることはまずないのだが。とりあえず、代替薬の候補としてこれだけあればまあ大丈夫だろう。
2020年6月
123456
78910111213
14151617181920
21222324252627
282930
2020年7月
1234
567891011
12131415161718
19202122232425
262728293031
2020年8月
1
2345678
9101112131415
16171819202122
23242526272829
3031

Powered by てがろぐ Ver 4.4.3

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