- 木俣ロバート久の weblog

概要

木俣ロバート久の日々の記録の垂れ流し

HTML の id について調べたら HTML 4.01 の頃のような制約が今やなく、1 文字以上で ASCII 空白文字以外であれば何でも良いことを知った

つまり、日付を id にしたいが為にわざわざ英字のプリフィクスを足して date2020-03-02 などとする必要は既にない

また、例えば以下の様な id も正しい値として処理する必要を想定しておかねばならない (そもそも仕様がどうあれ処理側は不正な値も想定しておくべきだが)

<p id='###'>###</p>
<p id='abc?query=efg'>abc?query=efg</p>
<p id='a>b{color:red;}'>a>b{color:red;}</p>

と言う訳でこの HTML を生成している処理も id へのページ内リンクを作成する際は URL エンコード処理を入れるようにした


上記とは別に、そもそも id に意味を持たせないようが良い場合が多いのでこの weblog の以降の記事見出しの id をランダムな文字列にした

例えば 2020 年 3 月 2 日のニュース記事に 2020-03-02 と言う id を振っていたが実は 3 月 1 日のニュースだったことが後で判明した場合、一度公開した id を変えるか、記事の日付と id を日付として読むとずれているのを許容するかという 2 択を迫られる事になるが、これはそもそも内容と無関係な id を振っておく事で回避できる

そう考えると URL 全体もランダムな文字列であった方が好ましいかもしれないが (上記の問題が http://example.com/2020/03.html#02 の ID 以外の部分でも同様に発生する) URL を完全にランダムにすると管理が面倒になるので今の所は考えていない

PowerShell 7 が release されていたので versino up

dotnet tool install --global PowerShell で更新を試みたが、は PowerShell 6.4 が install される状態だったので Releases · PowerShell/PowerShell · GitHub から installer を download して導入

また実行ファイルの install 先が標準で %ProgramFiles%\PowerShell\6\pwsh.exe から %ProgramFiles%\PowerShell\7\pwsh.exe に変わったので Visual Studio Core の setting.config 設定なども更新

ついでに Visual Studio Core の PowerShell 拡張も 2020.03 に update

とあるサイトの情報を目視で確認するが億劫になって web scraping で情報収集しようと画策

で、PowerShell でこんな感じで HTML を取得したはいいものの ParsedHtml が働かない

PS >[String] $Url = "https://example.com/";
PS >[Microsoft.PowerShell.Commands.BasicHtmlWebResponseObject] $WebResponse = Invoke-WebRequest -Uri $Url;
PS >$WebResponse.StatusCode

200
PS >$null -eq $WebResponse.ParsedHtml

True

検索したら Format data for BasicHtmlWebResponseObject contains ParsedHtml and Forms properties · Issue #5373 · PowerShell/PowerShell · GitHub と言う話があり、要するに ParsedHtml は廃止だよと

と言う訳でとりあえず Void Elements だけどうにかしたら -as [Xml.XmlDocument] で何とかなるのではと試してみることに

PS >[Regex] $voidElementPattern = "(<(area|base|br|col|embed|hr|img|input|link|meta|param|source|track|wbr)(\s+[^>='`"]+=(`"[^`"]+`"|'[^']+'))*\s*)>";
PS >($WebResponse.Content -replace "\n", " " -replace $voidElementPattern, '$1 />') -as [Xml.XmlDocument];

こんな感じでとりあえず Valid らしき HTML の void elements を XML で言う所の empty-element tag に書き換えて XML.XmlDocument に変換すれば何とかなるんじゃねと

Web scraping の話、結局取得した HTML が汚すぎて (素の状態で Valid ではない) 単に void element だけをどうこうしても全く解決せず

HTML 風の文字列から必要な情報を正規表現で抜き出した方が早いと結論して Invoke-WebRequest で取得したその時点の文字列に思い切り依存した正規表現とロジックを書いた

目的は果たしたが泥臭い実装なので相手側のサイト構造が変わったりすると一々コードの修正が必要になる

もしかしたら目視の方が結果楽かもしれない


後日この時期かと思い出すための時間のランドマークとして時事の話

昨今世界的に新型コロナウイルスによる肺炎が猛威をふるっている

日本では死者数は抑えられているものの感染拡大防止の為の様々な自粛による経済活動の停滞の被害が大きいように思える

日本はに消費税を上げて経済に打撃与えていた所なので尚更

他、マスクやトイレットペーパーのパニック購入などが散見される

Xbox Series X と PS5 の緒元が公開されているので比較してみる

Title Xbox Series X PlayStation 5
CPU 8 Cores, 3.8GHz Custom Zen2 8 Cores, 3.5GHz Custom Zen2
GPU 12 TFlops 1.825GHz Custom RDNA GPU 10.28 TFlops 2.235GHz Custom GPU
Memory 16GB GDDR6 16GB GDDR6
Memory Bandwidth 10GB at 560GB/s, 6GB at 336GB/s 448GB/s
Internal Storage Custom 1TB NVME SSD Custom 825GB SSD
IO Throughput 2.4GB/s (Raw), 4.8GB/s (Compressed) 5.5GB/s (Raw), Typical 8-9GB/s (Compressed)
External Storage 1TB Expansion Card USB HDD Support
Optical Drive 4K UHD Blu-Ray Drive 4K UHD Blu-ray Drive
Performance Target 4K 60 FPS, Up to 120 FPS 4K 120 FPS TV, 8K TV

Xbox Series X の CPU と GPU 性能が若干良く、PS5 の SSD のデータ転送速度が Xbox Series X より 2 倍程度良いと言う所だろうか

今の印象では PS5 の SSD の速度の方がゲーム中のストレスを減らしてくれるのではと期待している

また、そもそもの話として両機とも SSD が標準搭載されたこと自体が大きいとも思う

既存のゲーム機や PC の場合、マップの切り替え時などの読み出しが遅い HDD 内にデータがあるかもしれないので、次のマップで必要な全データを圧縮して main memory に書き出すなどの処理を行っていたと思うが、SSD が標準と知れている環境であればこのような処理の一部が不要になり、ローディング時間が早くなったり、よりデータ量の大きいマップを memory 上に展開できるようになるのではないだろうか

この weblog は Markdown file を取り込んで静的な HTML を生成する独自の PowerShell 製 CMS ツールで管理しているのだが、このツールが肥大化したため、一般的な HTML Extension とこの weblog 用 tool に Module を分けた

その際、weblog 用 tool は HTML Extension に依存しているので module manifest (.psd1) file に依存関係を記載した

が、記載すると Test-ModuleManifest の実行結果がエラーになる

なるので色々書き換えてエラーが出ない様になったら今度はエラーが再現しなくなった

つまり何かが悪かったことは分かるが、何が悪かったか分からないというプログラミングをしていると時々起こる例の奴になってしまった

エラーが起こっている最中は commit 等もしていなかったので今となっては本当に分からない

再現待ち


PowerShell の Module を依存関係を明示しつつ複数管理するノウハウを得たので複数の module で書いていた大体同じ処理を統一して纏め直すことができる

困ってはいなかったが今後の保守の手間を地味に減らせる