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

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

更新

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

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

No.1804 〔543文字〕 📗

Wall Street Journalは(もちろん)日本語版を読んでいるのだが、ふと気になったので記事原文の英語版を表示させてみたところ、明らかに日本語版よりも遙かに長くて驚いた。下記画像の左端が日本語版記事で中央が原文(英語)表示だ。
20200802000229-nishishi.jpg
一瞬、これだけの長い英文を日本語に訳すとこの程度の文字数で済むのかなと思ったのだが、全体を俯瞰して見るとそんなわけはなかった。^^; 詳しく見ると日本語版記事は628文字くらいなのだが、原文の英語記事は8,850文字ある。試しにDeepL翻訳に掛けてみると、無料版で一括翻訳できる限界の英語5,000文字分の日本語訳結果だけでも1,975文字あった。(^_^;;; DeepL翻訳の方が冗長になるので人間が自然な日本語に訳せばもう少し短くはなるだろうが、さすがに628文字にまではならないだろう。^^;
日本語記事での記載は外観をざっくり説明しているだけで、各国の誰々が何と言った、というような詳細は省いている感じだった。
これは、後々にアップデートされるのだろうか? ニュース記事は速度も重要だろうから、まずざっくりな簡易翻訳バージョンを公開しておいて、後から完全バージョンに差し替えるとかそういうこともあるのかな、とも思ったのだが。📗

No.2230 〔161文字〕 📗

続刊の発売を心待ちにしていたのはこれだ。
20200928212728-nishishi.jpg
さよならの言い方なんて知らない。」第4巻(新潮文庫nex)。写真は左が新刊、右が既刊。前巻がどんな終わりだったかをしっかり確認してから新刊を読まねば、と思ったので第3巻を本棚から出していて、終わり部分だけをいま読み返した。ああ、こんな終わりだったっけ。と、ずいぶん忘れていた。

No.3327 〔691文字〕 📗

稀に遭遇するのだが、「実際に作業してくれなくても、やり方さえ教えてくれれば良い(ので安くして欲しい)」という旨の要望を受けることがある。本当に稀で、滅多に遭遇はしないがゼロではない。しかし、「自分で作業する」のと「作業方法を教える」のとでは、後者の方が遙かに手間が掛かるのだ。「自分で作業する」場合はただ自分の頭で考えた作業を進めれば良いだけだが、「作業方法を教える」場合は(自分でもその作業を仮に進めつつ)1手1手その手順を文書化したり図示したりする手間がかかる。なので、「作業方法を教える」ということで手間が減ることはなく、むしろ大幅に手間は増えるのだ(たいていの仕事がそうだと思うが)。おそらく「ここをこう書き換えたら良い」的なアドバイスが存在すると思われているのかも知れないが、「ここをこう書き換えたら」と言えるなら、それは既に作業が完了している状態である。もちろん「ここを」の対象は少なく見積もっても数百行くらいはあるのだ。参考書を読んで学ぶ手間を省くために教師を雇ったら、教師代の方が高くつくだろう。おそらくそれは誰でも分かっているだろうが、それでもなお「やり方さえ教えてくれたら」云々と言ってしまうのは、「ちょっと方法を知れば簡単にできる」と思われているのかもしれない。もしくは、「情報は無料だ」と思われているのかもしれないが(その方がより酷い)。思うのは自由なのでその点に文句はないのだが、そういう方とは極力仕事をしたくない。経験的に、精神力を必要以上に消耗すると分かっているからだ。仕事を長く継続させる良法は、無駄に精神力を消耗してしまう機会を排除することである。

No.3345 〔572文字〕 📗

世の中には部屋を真っ暗にしないと眠れない人も居るようだが、長年の試行錯誤から私は真逆だと分かった。私は室内にある程度の灯りがないと眠れない。もちろん真っ白な蛍光灯色の灯りで室内を照らした状態では寝ないが、淡い橙色の灯り(デスクに置けば読書が可能な程度の光量が必要で、豆電球では全然足りない)くらいはあった方が良い。光源が直接目に届かない間接照明のような感じになる配置で灯りを置いている。適度なホワイトノイズもあると望ましい。ちょうど良いのがタワーPCの稼働音(主に冷却ファンの音)なので、PCの電源は寝ているときも入れっぱなしである。ついでに液晶ディスプレイの灯りもある。寝るときに液晶ディスプレイは見ない方が良い云々と言われるかもしれないが、別にモニターの真ん前で寝ているわけではない。それは間接照明くらいにしかなっていないので何も問題ない。長年「寝るときには真っ暗に」という世間の常識(?)に縛られて気付けなかったのだが、室内に多少の明るさ(とホワイトノイズ)を維持するようになってからは明らかによく眠れるようになった。必要な明るさの目安は、壁に貼ってあるさくらたんポスターがギリギリ見えるくらいである。明るいとメラトニンの分泌が抑制されてしまうが、それは網膜に直接光が入っていたらの話なようなので、間接的な灯りだけだったら問題ないようだ。

No.3995 〔820文字〕 📗

画像の遅延読み込み(画像の掲載場所付近までスクロールしない限り画像ファイルを読み込まないようにしてくれるブラウザ側の機能で、HTML5で正式に追加された仕様)は通信量削減に役立つので、最近では問答無用でimg要素にloadiong="lazy"を加えている。ただ、この属性を加える際には注意しないと、ページ内リンクの移動距離が正しくなくなって、ページ内リンクがうまく機能しなくなることがある。その原因は、img要素にwidthやheight属性を書いていないことだ。昨今、レスポンシブなデザインが当たり前になったので、img要素にwidth属性もheight属性も書かないことが多かったのだが(CSSでサイズを指定するからHTMLにサイズを書いても無駄だろうということで)、widthやheight属性を省略してしまうと、実際に画像が読み込まれるまで専有面積が分からないので、ページ内リンクで長距離を移動する際には移動先の座標がズレてしまうのだ。これを防ぐには、とりあえずwidthとheight属性をimg要素に書いておくこと。実際に表示されるサイズである必要はなく、たぶん縦横比が分かれば良いのだと思うので、画像の原寸サイズでも指定しておけば良い。このwidth・heightの両属性がHTMLにあれば、CSSと組み合わせることで画像の表示面積が分かるので、遅延読み込みによって画像が読み込まれていなくてもページ内の座標が確実に決まるから、ページ内リンクがズレることもない。HTML側でサイズの指定がなくても、CSS側でピクセル単位でサイズが指定されていれば問題はないだろうが、レスポンシブWebデザインだとたいてい画像サイズは割合で指定されているから、画像の縦横比が(HTMLから)分からないと実際の表示面積が計算できない。もしかしたら業界では当たり前のことだったかも知れないのだが、私はそこに気付くのに結構な時間が掛かってしまった。

No.4092 〔1035文字〕 📗

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

No.5099 〔1417文字〕 📗

G7各国の中でのCOVID-19ワクチン接種率ではカナダに次いで日本が2位という話がTwitterで流れてきたので、そのソースになっているourworldindata.orgでグラフを出してみた。たしかに6月からほぼ一定ペースで線形に伸びているところはすごい。ただ、ほぼ同じ時期に勢いよく伸ばせたカナダが一番すごいが。なんでこんなに一気に伸ばせたのか。人口も理由の1つだろうか? カナダの人口は約3,800万人くらいらしいので。とはいえ、国土面積は広いのだから、人口が少ないという理由だけで打ちやすくなるわけではないだろうけども。ただ、ワクチンは数の確保が難しかったので人口が少なければ調達の難易度は下がる気はする。他国の人口は、接種率の高い順に、イタリア(約5,960万人)→フランス(6,740万人)→英国(6,720万人)→ドイツ(8,320万人)→米国(3.3億人)である。と書いてみて気付いたのだが、G7の中で一番人口が少ないのはカナダだったのか。今までそこを比較してみようと思ったことがなかったので気付かなかった。ワクチン製造会社を抱えている米国と英国はさすがに早くから伸びているが、アメリカは早々に伸び悩んでしまっている。人口が多くて国土も広いが物流も技術も高いわけだから、理由は自由すぎる国だからだろうか? 英国も65%くらいまでぐんぐん伸びていたのに今は伸び悩んでいるが、これは何故だろうか。なお、G7の枠組みで比較することにあまり意味はなさそうなので、世界で人口の多い国家ランキングで1位から11位まで(※日本が11位)の国家も比較してみた。それが2枚目のグラフである。ずーいぶん明確な差が付いてしまっている。日本の伸び方がめちゃくちゃ特徴的な気がする。(^_^;) 製薬会社を抱える米国の優位さもよく分かるが。中国は14億人も人が居るのに本当にここまで打てているのか(グラフでは10月23日時点で73.92%)。ただ、国民が何人だろうと、ワクチンの数さえ確保できていれば国家が打たせようと思えば打たせられる国ではあるとは思うが。^^; ロシアはずいぶん初期に自前のワクチンを開発したと言っていたが、まだ32%しか打てていない。たしかNewsweekの記事か何かでロシアに駐在している記者のレポートがあって、外国人でも手続きさえ踏めばワクチンを打てたというような話を読んだ気がするが。ただ、どこ製のを打てたのかは覚えていない。たしかロシア製以外もあるが何を打てるかは自分では選べず直前になるまで分からないという話を読んだことがあるのだが、それがロシアの話だったかどうかは記憶にないので別の国の話かもしれない。接種率が低いのは、単純にワクチンを打ちたい人が少ないのだろうか? ロシア人でもロシア製は打ちたくないということ? ロシアの人口は1.45億人で、日本より2千万人くらい多いだけだ。ただ国土は広いが。13.6億人のインドは残念ながらまだ23%のようだ。仮に日本と同じ分量を同じペースで調達(と接種)できたとしても10倍以上の時間が必要なわけだものな。ただ、インドは提携工場を使ってむしろワクチンを製造(輸出)している側だったような気もするのだが。ファイザー製やモデルナ製はかなり低い温度で輸送する必要があるので、交通インフラと医療設備が整っていない地域では苦しいという話がそういえばあったな、と思い出した。
202110302108441-nishishi.png 20211030210844-nishishi.png

No.5310 〔2824文字〕 📗

PCのデータは日々自動バックアップされる仕組みを用意してあるのだが、バックアップ先は「バックアップ用途の内蔵HDD」である。システムやデータを格納するSSDと、パーティションイメージを格納するバックアップ用HDD(※SSDではなくHDDなのは大容量が必要だから)を内蔵させてある。なので、あくまでも同一PC内でバックアップしているだけだ。この場合、ミスやトラブルでデータが失われた場合にはバックアップから復活させられるが、PC全体に及ぶ問題が起きたとき(雷にやられるとか水没するとか盗難に遭うとかランサムウェアに乗っ取られるとか)には対処できない。ので、外部の2ndバックアップもある方が望ましいよな……とは思っていた。最低限、システムドライブとデータドライブだけを外部にバックアップする用途でKIOXIAの128GBくらいのUSBメモリを調達しようかなと考えていた。最初にチェックしたときには3,480円だったが、今はブラックフライデーのタイムセールで2,955円(クーポンでさらに10%OFF)とかになっていたし。しかし、USBメモリは長期保管に向いているわけではないし、どうせならUSBポータブルHDD(またはSSD)の方が良いのではないか、と思って検索してみた。しかし、メジャー処の製品は結構な値段がするし、安い製品は品質が心配だし、何より最近のAmazon返品詐欺の被害も心配である。
ふと、SerialATA機器をUSB接続する変換ケーブルを所有していることを思い出した。それならば、内蔵用のHDDやSSDを単体で調達すれば良いではないかと。用途は「バックアップデータのバックアップ」なので、使用頻度はまあ数ヶ月に1回くらいで良いだろう。とすると、内蔵用のHDDやSSDをUSB接続するのでも問題ない。普段は箱にでもしまっておけば良いのだから。……と考えてみたところで、さらに思い出した。そういえば、退役させた内蔵HDDがいくつかあったはずではないかと。HDDは故障の予兆を感じて交換するケースもあるが、容量が足りなくて交換するケースもある。特に過去のバックアップ用HDDは、さらなる大容量が必要になって退役させたものがいくつかあった気がする。それらは容量以外には問題がないのだから、再活用しても問題ない。というわけで探してみたところ、2016年の夏頃に退役させたWestern Digital社製の1TB HDDを発見した。2010年製造なのでおそらく6年間くらいバックアップ用HDDとして使っていたのだろう。早速これを、SerialATA-USB変換ケーブルに挿してPCに接続してみた。……が、認識がおかしい。ストレージ機器だとは認識されているようだがドライブとしては認識されない。どうやら3.5インチのHDDだとUSB給電では電力が足りなくて動かないようだ……。まあ、若干そうだろうなと思ってはいたのだが。元々このケーブルは、ノートに内蔵している2.5インチHDDをSSDに交換する用途で買ったものなので、3.5インチHDDを接続したことはなかったのだ。というわけで、内蔵HDDのUSBポータブル化はできなかったのだが、せっかく発見された1TB HDDを無駄にはしたくない。ポータブルHDDで容量1TBの製品を買おうと思ったら結構な値段がするのだし。
で、メインPCには4台の3.5インチHDDまたはSSDを内蔵できる空間があるのだが、今は3台しか内蔵させていない。なのでそこに一時的に入れれば良い。HDDはフロントアクセスパネルから交換できる筐体なので、HDDを内蔵させるために筐体を開ける必要はない。HDDをストレージホルダーに4個のネジで留める手間はあるが、使用頻度は少ないのだから良しとする。早速内蔵させてみると問題なく認識した。CrystalDiskInfoによると、12,491時間ほど使ったHDDのようだ。日に換算すると520日である。電源投入回数は4,186回。結構使っているが、特にハードウェアの問題はなさそうなので、まあ、時々接続してバックアップデータをバックアップする用途なら全然問題ないだろう。
202111262236411-nishishi.png
中身はすべて必要ないので、一旦フォーマットすることに。NTFSから変更する必要もないのでクイックフォーマットをすれば高速で終わるのだと思うのだが、試しに普通にフォーマットさせてみた。1TBのフォーマットが終わるのに3時間半くらいかかるのだな。最初の頃は100MB/sくらいの速度で進んでいたが、終わりの頃は50MB/sくらいになり、終盤は25MB/sくらいになっていた気がする。ずーっと見ていたわけではないのでハッキリとは分からないが。HDDは記録位置でそこまで(4分の1になるほど)速度が変わるのか。フォーマット中でもPC上で他の作業はできるので、特に問題はなかった。
20211126223641-nishishi.png
フォーマットが終わってから、バックアップ用HDDの中からパーティションイメージの完全版(普段は高速化と容量節約のために差分バックアップされる)を、この再活用1TB HDDにコピーしてから、再度シャットダウンしてHDDを取り外した。さすがにHDDは寒い部屋の中でもほんのり暖かい。このHDDに「内蔵バックアップHDDの2ndバックアップ用途」とラベルを貼って、HDD購入時のプラケース(このHDDを買ったときのケースかどうかは分からないが、サイズは3.5インチなら何でも一緒なので問題ない)に入れて保管しておくことにする。
そんなわけで、新しい外部ストレージ機器を調達することなく、余っていたHDDで外部バックアップ手段を用意できた。今のところ、容量が1TBあればメインPCと仕事用PC両方の全パーティションのイメージ(圧縮されている)を格納しても足りるので、しばらくは問題ないだろう。あとは、数ヶ月に1回くらいこの2ndバックアップHDDのことを思い出して、時々コピーすれば良さそうだ。数ヶ月に1回だと、本当にこの2ndバックアップが必要になったときに数ヶ月分の更新内容が失われるわけだが、そもそもこのバックアップが「2重目」のバックアップなのだ。普段の完全なバックアップは内蔵のバックアップ用HDDにある。それすらも失われてしまったときに、何もかもがゼロになるのを防ぐためのバックアップなので問題ないだろう。日常のクリティカルなデータ(仕事のデータとかメールとか開発ソフトのデータとか)は、バックアップ用HDDにバックアップされるほかに、メインPC(ミニタワー)と仕事用PC(ノート)とで相互に同期しているし、ごく一部はネット上の小容量なストレージにもあるので、既に多重なバックアップになっている。なので、今回用意した2ndバックアップHDDは、本当に必要になることはまずないと考えている、保険の保険みたいなものだ。

No.5711 〔796文字〕 📗

データ用のSSDを新しいものに交換した。13ヶ月ほど使っていたSunDisk製のSSDで「読めないセクタがある」というエラーが出るようになってしまったので、新たに調達したWestern Digital製のSSDに交換した。
20220121225810-nishishi.jpg
旧SSDから新SSDにパーティションごとクローンを作成すると、「読めないセクタがある」というエラー報告が少なくとも400回出た……。orz 400回で済んだわけではなくて、400回を超えた時点で数えるのをやめて「すべて無視」の選択をしたので、合計でどれくらい読めないセクタがあるのかは把握していない。もうちょっと早めに交換すべきだった。エラーが報告される対象のパーティションは、長期保管用のストレージとして使っている領域であって、日々のデータを蓄積するパーティションは別なので、大きな問題はないと思うのだが。念のために、エラーが出始める直前の時期に作成されたバックアップイメージを隔離して保管しておくことにした。今後、何らかの読めないファイルが出てきたら、そこから書き戻すことにする。次にPCを組むときには、やはりRAID1を構成すべきだ。バックアップイメージは、「失われたファイルがどれなのか」が特定できる場合には役に立つが、「どれなのかは分からないが何かが失われている可能性がある」みたいな状態だとバックアップから書き戻すのは難しい。幸い、「一度保管したら更新することはまずない」というストレージ用途のパーティションでエラーが出ているだけだったので、ちょっと古めのバックアップイメージから上書きさせてはみたが。バックアップと比較すると約1万ファイルほど存在しないことが分かったのだが、それはエラーで消えたのか、それとも過去の私がファイルを整理して消した結果なのか判別できない。うーむ、こんな問題があったとは。新しいSSDは、長く保ってくれると良いのだが。

No.6013 〔261文字〕 📗

すげえ。PowerToysをVer 0.56.1にバージョンアップしたら、マウスポインタの位置をスポットライトで照らしてくれる機能が、マウスシェイク(マウスを左右に振る動作)でアクティブ化されるようになっていた……! めちゃくちゃ便利! これ、あらゆるWindowsユーザに便利なのでインストール推奨だ。
202203011205201-nishishi.png 20220301120520-nishishi.png
これでもう、マウスポインタの位置が分からなくなっても、マウスを左右に振るだけの簡単操作で絶対にすぐに見つけられる。試したところ左右に3回振る(3往復する)必要があるようだ。2回では反応しなかった。

No.6020 〔419文字〕 📗

続刊を楽しみに待っていた「さよならの言い方なんて知らない。第6巻を手に入れた。前巻からちょうど1年ぶりである。
20220303102951-nishishi.jpg
前巻で、物語の見方が180度変わるような全く予想しなかった背後が明かされて、この話がどう決着されるのかさっぱり分からなくなってきた。作者はいつの時点からこの展開を考えていたのかがとても気になる。1~2巻は「ウォーター&ビスケットのテーマ」というタイトルで角川スニーカー文庫から出ていて、その後に「さよならの言い方なんて知らない。」に改題されて新潮文庫nexから新たに刊行されて今回6巻まで来た。角川スニーカー文庫版の表紙では私が主人公だと認識してきた2人が描かれているのに対して、新潮文庫nex版の表紙では第1巻の時点から(誰なのか分からない)全く異なる人物が描かれてきた。これが誰なのかが判明した衝撃の巻が前巻(第5巻)だった。なので、新潮文庫に移った時点でこの展開が決まっていたのは明らかだが。

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.6556 〔561文字〕 📗

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

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