概要
木俣ロバート久の日々の記録の垂れ流し
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 で書いていた大体同じ処理を統一して纏め直すことができる
困ってはいなかったが今後の保守の手間を地味に減らせる