portal shit!

年が明けてからやるのはどうかと思うが、タイミングがなかったので今さらながら 2022 年のふりかえり。

ランニング

2022 年はよく走った。これまでも何度か走ってると書いていたが、ちゃんとグラフにしてみると 2022 年の 8 月までは大して走っておらず、 2022 年の 9 月から本腰を入れて走るようになったようだ。

オレンジ色の線が 2022 年のもので、9 月から傾きが急になっている。 9 月は月間 110km 走った。月間 100km はフルマラソンに出られる基準のようなのでこの頃は調子こいていた。

ランニングの頻度を上げるのに役立ったのが計画表だった。それまで漫然と走っていたが、漫然と走っていると月間 100km も走れないことに気がついた。自分は一回 5km 走っているが、それを気が向いたときに週 2, 3 度やるだけだと月間 50km くらいにしかならない。きちんとランニングした日と距離を確認していかないと目標には辿り着かない。ログは Apple Watch で取得しているが、統計データとしては見られない。なので HealthFit というアプリを使っているが、 HealthFit では目標設定ができないので Numbers でシートを作って管理することにした。これは元はてなのディレクターの二宮さんの記事の真似。

強い気持ち - 二宮日記

Webディレクター解体アドベントカレンダー最終日の記事です。今から4年前にも、アドベントカレンダー最終日の記事を書きました。それは、ディレクターにとって気持ちが一番大事だという、些か青臭い話です。 あれから4年、早いものですね。今読み返すとちょと恥ずかしいほどエモいこと言ってますけど、まあでも、今でもそう思ってます。やっぱり物事を前に進めるって言うのは、スキルとかテクニックとか、そういう技術だけでは補えないものがありますよね。 特にサービス開発って、絶対すんなり行かないじゃないですか。絶対途中で何かありますよね。何のハプニングもアクシデントもインシデントもない大規模プロジェクト、今まで1つでも…

ninomiyateppei.com

こちらが年間の週次のランニング計画。

こちらが月間の日次のランニング計画。

月間のシートに日次の目標と実績値を入れると、年間の週次のシートに自動反映される仕組みになってる。これによって自分は一週間に何 km 走る予定で現在目標に対してどのくらい達成しているのかを確認できるようになる。

37signals の本を読んで、計画を立てるのはアホだ、数値目標なんて意味がない、未来を先読みすることはできない、という発想に影響されて計画を立てたりするのは何となく良い印象を持っていなかったけど、月間何キロくらい走りたいとか、ベンチマークとなる具体的な数値目標がないとなかなか実績は積み上がっていかないと思う。もちろんまだ走ったことがない状態でいきなり月間 100km のような目標を立てるのは愚かだと思うが、そこそこ走れるようになってきたら（自分の力がわかるようになってきたら）計画を立てたり数値目標を設定したりするのは悪くないことだと思う。

9 月にがむしゃらに走ったおかげか、最近は走るペースが一段速くなっていて、 1km を 5 分台で走れるようになってきた。今年はちょっと色気を出して初心者向けのトレランの大会に出てみようかと思ってる。

登山

4 月に脊振山系全山縦走、 11 月に九州脊梁に行った。夏に北アルプスを予定していたが、ちょうどコロナにかかって行くことができなかった。何にせよ最近は山に登るのよりも近所を走る方が楽しいので山への足が遠のいた一年だった。登山時の体力作りで走り始めたのに本末転倒している。

仕事

一昨年は結構でかい成果を出せたが 2022 年はぱっとしない一年だった。反省したい。

生活

iPhone を買い換えて 11 から 14 Pro になった。カメラが三つになって望遠の写真を撮れるようになったのが便利。 Dynamic Island も便利。タイマーかけてるときに常に Dynamic Island で残り時間を確認できるのは相当便利。 164800 円払ってよかった（ 36 回ローン）。

サウナにハマってぼちぼち行っていた。サウナーの人たちのように一週間に何回も通うというほどではないが、金曜日の仕事帰りにサウナまで走って行ってサウナに入って帰るというのを何回かやった。花金感が出て良い。

2020 年に車を買い換えたがあまりドライブしてない。アメ車なので燃費が悪い、コロナなので出かけづらい、などいろいろあるが、せっかく車を買い換えたのに使わないで置物になってるのはもったいないので有効活用したい。

そういえば 2022 年は YouTube をよく見た。 YouTube Premium に入ったので広告が表示されなくなり、邪魔が入ることなくとてもなめらかに動画を視聴できるようになった。 Netflix はあまり見ていなかったので解約し、 YouTube で素人が上げる動画をよく見た。ストーリーのない、ただ料理をしているだけとか、ただ穴蔵を掘っているだけの 15 分くらいの動画を見るのがちょうどよい。 Netflix の動画は長いし、ことあるごとに金、暴力、セックスを意識させられるので見るのがきつい。こってりしすぎている。

ブログ

Tantivy を導入して全文検索できるようにした。検索も見た目を変えてインクリメンタルサーチできるようにしたりした。年に一回くらいはバズる記事を書きたいが、 2022 年は不作だった。反省したい。

総括

仕事や生活、ブログは本当にぱっとしなかった。その代わり走ることを頑張っているのかも知れない。ランニングや登山は、大して頑張って生きていないのに走ったり山に登ったりするとめっちゃ頑張ってるかのような錯覚を得られて自己肯定感が高まる。仕事などでもちゃんと成果を出しつつ走ったりできたら良いのだけど自分の場合は逃避になってるような気がする。しかし走るのをやめたら仕事で成果を出せるかというとそうでもないし、遺伝的に糖尿病のリスクがあるので発症しないように死ぬまで走り続けるしかない。 2023 年は運動しつつ仕事やブログ書きでも一定の成果を上げたい。あともうちょいサウナに行きたい

iPhone 14 Pro に変えてからランニング中に写真撮るのが楽しくなった。背面の三つのレンズは醜いが、様々なズームレベルで写真が撮れるのは楽しい。

一つ前の記事では「やっぱりカメラにはかなわない」と書いているが、まぁセンサーサイズとかレンズの性能が違うので当たり前で、手軽に撮れるのにこの画質はやっぱりすごいと思う。晴れた日の昼間はかなり画質よい。夕方も露出を落とせばなかなかよい写真が撮れる（一枚目）。 iPhone 14 Pro 、買って良かった。

去年、 Rebuild ポッドキャストで miyagawa さんがプロジェクターの話をしているのを何度か聞いて気になるようになりプロジェクターを買った。コロナ禍なので映画館に行きづらいし、居間のテレビのチャンネル選択権は自分にはないので寝室の壁に映して見られるプロジェクターを導入した。 Anker の Nebula Cosmos というもの。 明るさが 900 ANSI ルーメンあって、昼間でもカーテンを閉め切ればなんとか視聴可能。Android TV 内蔵で基本的にこれ一つあれば動画配信サービスの動画が見られる。コロナにかかってしんどいときもプロジェクターで動画を見て凌いだ。

プロジェクターで一番見たのはおそらく YouTube で、中田敦彦のYouTube大学、伊豆のぬし釣り、海外のキャンプ動画や登山動画をよく見た。海外の動画は画質が当たり前のように 4K で撮影・編集技術ともに高く（基本的に自撮りだが、三脚と複数台カメラとドローンを駆使していて映画並の映像クオリティ）、プロジェクターの大画面で見ると凄かった。この手の映像で魅せる系の動画はスマートフォンや Mac のディスプレイでは良さがわからなかったと思う。

その次によく見たのは Apple TV+ で、モーニングショーやテヘラン、テッドラッソあたりを見た。いまもフォー・オール・マンカインドを見てる。 Apple TV+ のドラマはどれも高画質なのが良い。なお Android TV にもちゃんと Apple TV アプリがあるので Apple TV+ の作品を問題なく視聴できる。素晴らしい。

プロジェクター、概ね満足しているが、不満な点としては以下。

ファンの音が少しうるさいのと夏場は排熱が厳しいと感じる。また部屋が狭く壁正面にプロジェクターを配置できなかったので斜めから投影しており（日本の住宅事情だとこういう設置方法が多いと思う）、補正が必要になる。角度補正機能はあるが、ちょいちょいズレるので手動で補正する必要がある。

しかしこれらはまだ許容範囲で、最も不満なのが Netflix が完全対応していないことだ。 Netflix は著作権的なアレでプロジェクターでのアプリ動作を拒んでいるようで、 Nebula で Netflix を見るためには Nebula Manager というモバイルエミュレーターのようなアプリを Google Play でインストールし、そのなかにスマートフォン版の Netflix アプリをインストールしなければならない。しかもこのスマートフォン版 Netflix は Nebula 付属のリモコンで操作できず、いちいちスマートフォンの専用アプリで操作する必要がありはちゃめちゃに使い勝手が悪い。極め付けは画質の悪さで、せっかく Full HD のプロジェクターで投影してるのにスマートフォン版 Netflix は SD 画質なのでぼやけたり滲みのある映像になってしまう。

ちゃんとした Netflix アプリを使うには Apple TV や Fire TV 、 Chromecast などを使えば良いのだが、 Netflix のためだけにそこまでするのはどうだかなぁという感じがするので未導入。結果として Netflix を見る頻度が落ちてとうとう解約してしまった。 Netflix オリジナルコンテンツは「金、セックス、権力」というような番組が多かったので食傷気味だったしこれでよかったのかもしれない。今後は YouTube と Apple TV+ と Amazon Prime Video を見て過ごすことにする。

ダークモードとライトモードの切り替えをグローバルナビゲーション（上の方の半透明の白い領域）から簡単に行えるようにした（これまではこのサイトについてのページで切り替える必要があった）。デフォルトは OS の設定準拠で、 OS がダークモードであればダークモードに、ライトモードであればライトモードで表示される。手動でテーマを切り替えると Cookie に設定値を保存する。機能と見た目は MDN Web Docs を参考にした。

CSS がぐちゃぐちゃなのでかなり難儀した（ 3 年前にも同じことを書いている）。ダークモードとライトモードの切り替えなんて自分しかしていないと思うがかなり満足度の高い休日プログラミングだった。

Rust 製の全文検索システム Tantivy を Ruby から使える Tantiny を導入したことを書いた。

Rust 製の全文検索システム Tantivy を Ruby で使える Tantiny を導入した

過去記事の効率的な閲覧方法を模索し、全文検索システムTantivyとそのRubyクライアントTantinyを導入した。個人ブログでも高機能な検索が可能になり、技術の進歩を実感している。

portalshit.net

結構手軽に使えるのだがやはり日本語のトークナイズ（形態素解析）ができないのでいまいちなところがあった。 Tantivy には lindera-tantivy というものがあって、 Lindera は kuromoji のポートなので、これを使うと日本語や中国語、韓国語の形態素解析ができる。 Tantiny に導入できないか試してみたが、自分の Rust 力では到底無理だった。

ちなみに関連記事の表示でも日本語の形態素解析は行っている。

⛓TF-IDF で関連エントリーを表示

cho45氏の手法を参考にLokkaにSimilarityモデルを追加し、MeCabで名詞を抽出してTF-IDFを計算、ベクトル正規化して類似エントリを検出・保存するRakeタスクを実装した。並...

portalshit.net

MeCab に neologd/mecab-ipadic-neologd を組み合わせてナウな日本語に対応させつつ形態素解析している。

この仕組みを作ってトークナイズは Ruby で自前で行い、 Tantiny および Tantivy にはトークナイズ済みの配列を食わせるだけにした（ Tantiny はトークナイズ済みのテキストを受け付けることもできる）。トークナイズを自前で行うことで辞書ファイルで拾いきれないような固有名詞もカバーできる。例えば 山と道 なんかは MeCab と mecab-ipadic-neologd にトークナイズさせると 山 と 道 に分割されてしまう。自前のトークナイザーで単語として認識させていている。おかげで「山と道」をちゃんと検索できるようになっている。

なお、自前のトークナイザーはこんなコードになっている。

class Tokenizer
  attr_reader :text

  class << self
    def run(text)
      self.new(text).tokenize
    end
  end

  def initialize(text)
    @text = text
  end

  def cleansed_text
    @cleansed_ ||= text.
      gsub(/<.+?>/, '').
      gsub(/!?\[(.+)?\].+?\)/, '\1').
      gsub(%r{(?:```|<code>)(.+?)(?:```|</code>)}m, '\1')
  end

  def words_to_ignore
    @words_to_ignore ||= %w[
      これ こと とき よう そう やつ とこ ところ 用 もの はず みたい たち いま 後 確か 中 気 方
      頃 上 先 点 前 一 内 lt gt ここ なか どこ まま わけ ため 的 それ あと
    ]
  end

  def preserved_words
    @preserved_words ||= %w[
      山と道 ハイキング 縦走 散歩 プログラミング はてブ 鐘撞山 散財 はてなブックマーク はてな
    ]
  end

  def nm
    require 'natto'
    @nm ||= Natto::MeCab.new
  end

  def words
    @words ||= []
  end

  def tokenize
    preserved_words.each do |word|
      words << word if cleansed_text.match?(word)
    end

    nm.parse(cleansed_text) do |n|
      next unless n.feature.match?(/名詞/)
      next if n.feature.match?(/(サ変接続|数)/)
      next if n.surface.match?(/\A([a-z][0-9]|\p{hiragana}|\p{katakana})\Z/i)
      next if words_to_ignore.include?(n.surface)
      words << n.surface
    end

    words
  end
end

preserved_words が手製の辞書だ。 はてな や はてブ も辞書登録しておかないと MeCab だとバラバラに分割されてしまって検索できなかった。

難点としては記事更新後に自動でインデックスの更新が行われず、 cron によるバッチ処理でインデックス更新を行っている[^{1]。なので検索インデックスにデータが反映されるまでにタイムラグがある。} Tantiny でやれれば記事作成・更新時のコールバックとして処理できるのでリアルタイムに変更を検索インデックスに反映させることができるが、個人の日記なのでタイムラグありでも大きな問題にはならない。

本当は Tantiny で lindera-tantivy を使えるようにして Pull Request がカッチョイイのだが、とりあえずは自分は目的が達成できたので満足してしまった。 5 年くらい前から Rust 勉強したいと思っているが、いつまでも経っても Rust を書けるようにはならない。

[^1]: mecab-ipadic-neologd を VPS 上でインストールできず（めっちゃメモリを使う）、手元の Mac で Docker コンテナ化して Docker Hub 経由でコンテナイメージを Pull して VPS 上で Docker 経由で動かしている（その辺について書いてる記事: ブログのコンテナ化を試みたけどやめた）

以前、以下の記事でこのウェブサイトへのアクセス元 User Agent について書いた。

誰がこのブログのフィードを読みに来ているのか

ブログのフィード閲覧ログを解析し、上位アクセス元が想定外にSlackbotや各種リーダーのクローラーだったことを報告。FeedlyよりFastladderや有料サービスの存在が目立ち、購読者数を...

portalshit.net

そのとき Hatena::Russia::Crawler というのが謎だということを書いた。最近のアクセスログを見ても相変わらずこの User Agent からのアクセスが多い。またアクセス頻度も高く、同一の URL に対して何度もアクセスしている。

これはやはりはてなの名を騙った怪しいクローラーなのではないかと思い調べてみた。

まず Hatena::Russia::Crawler という User Agent からのアクセスの IP アドレスを調べてみたところ以下だった。

cat log/access.log | grep 'useragent:Hatena::Russia::Crawler/0.01' | cut -f2 | sort | uniq -c | sort -nr
    434 remote_addr:52.68.0.227
    419 remote_addr:54.249.85.140
    417 remote_addr:54.92.97.59
    379 remote_addr:54.250.227.185

whois してみると AWS で運用されているものであることがわかるが、はてなのものかは断定できない。

もしこの IP からはてなブックマークやはてなアンテナなどの User Agent でのアクセスもあれば Hatena::Russia::Crawler ははてなのクローラーであると断定できるだろう。ということで調べてみたところこんな感じだった。

zcat -f log/access.log* | grep -E 'remote_addr:(52\.68\.0\.227|54\.249\.85\.140|54\.92\.97\.59|54\.250\.227\.185)' | cut -f13,2 | sort | uniq -c | sort -nr
  16687 remote_addr:54.250.227.185      useragent:Hatena::Russia::Crawler/0.01
  16448 remote_addr:54.92.97.59 useragent:Hatena::Russia::Crawler/0.01
  16370 remote_addr:54.249.85.140       useragent:Hatena::Russia::Crawler/0.01
  16272 remote_addr:52.68.0.227 useragent:Hatena::Russia::Crawler/0.01
     73 remote_addr:54.249.85.140       useragent:HatenaBookmark/4.0 (Hatena::Bookmark; Scissors)
     60 remote_addr:54.250.227.185      useragent:HatenaBookmark/4.0 (Hatena::Bookmark; Scissors)
     56 remote_addr:52.68.0.227 useragent:HatenaBookmark/4.0 (Hatena::Bookmark; Scissors)
     50 remote_addr:54.92.97.59 useragent:HatenaBookmark/4.0 (Hatena::Bookmark; Scissors)
     31 remote_addr:54.92.97.59 useragent:Hatena::Fetcher/0.01 (master) Furl/3.13
     31 remote_addr:54.250.227.185      useragent:Hatena::Fetcher/0.01 (master) Furl/3.13
     31 remote_addr:54.249.85.140       useragent:Hatena::Fetcher/0.01 (master) Furl/3.13
     26 remote_addr:52.68.0.227 useragent:Hatena::Fetcher/0.01 (master) Furl/3.13
     19 remote_addr:54.92.97.59 useragent:Hatena::Scissors/0.01
     19 remote_addr:54.250.227.185      useragent:Hatena::Scissors/0.01
     16 remote_addr:52.68.0.227 useragent:Hatena::Scissors/0.01
      9 remote_addr:54.249.85.140       useragent:Hatena::Scissors/0.01

なんと、 IP アドレスで検索してはてなのその他のクローラーもヒットしてしまった。つまり Hatena::Russia::Crawler ははてなのクローラーということだ。

ただしググっても一切情報が出てこない。 Hatena::Russia::Crawler で検索してトップヒットするのは自分のブログだ。

改めて Hatena::Russia::Crawler による直近 30 日間のアクセス状況を調べてみるとこんな感じだ。

zcat -f log/access.log* | grep 'useragent:Hatena::Russia::Crawler/0.01' | cut -f5 | sort | uniq -c | sort -nr
  15697 request_uri:/index.atom
   9913 request_uri:/2022/04/20/integrate-charts-category-with-select-boxs
   9373 request_uri:/2022/05/04/reputation-and-interpretation
   8422 request_uri:/2022/05/11/fly-to-kamikochi-from-fukuoka
   7716 request_uri:/2022/05/16/using-tantivy-over-tantiny
   5906 request_uri:/2022/04/17/quit-using-hey
   5139 request_uri:/2021/12/29/thoughts-on-manga-subscription
   1308 request_uri:/2021/12/13/keep-a-stack-books-whether-reading-them-or-not
    787 request_uri:/2022/06/23/each-entry-title-should-be-marked-up-with-h1
    741 request_uri:/2021/12/13/keep-stack-books-whether-reading-them-or-not
    456 request_uri:/2022/06/24/if-you-feel-apple-musics-recommendation-is-awful
    100 request_uri:/2022/06/14/thoughts-on-hatena-bookmark
     46 request_uri:/2015/12/07/thoughts-on-rural-life
     46 request_uri:/2015/12/02/thoughts-on-t-on-t
     46 request_uri:/2015/12/02/thoughts-on-christmas-song
     45 request_uri:/2019/12/02/stop-drinking-outside-frequently
     16 request_uri:/2020/11/08/where-i-went-in-2019
     11 request_uri:/2015/12/05/omm-writer-music-is-nice-to-listen-to-while-writing
      5 request_uri:/2022/05/04/the-golden-maintenance-week
      2 request_uri:/2022/06/24/
      2 request_uri:/2022/06/24

index.atom はフィードの URL なので除外するとして、特定の記事に対して数千回もアクセスがある。 30 日間で 9000 回ということは一日あたり 300 回だ。 1 時間あたり 12.5 回である。何のためにこんなに高頻度でクローリングしているのだろうか。

とここまで調べたところほかの Bot 系アクセスはどうなのかと改めて User Agent 毎のアクセス数を調べてみたらこんな感じだった。

zcat -f log/access.log* | cut -f13 | sort | uniq -c | sort -nr | head -10
 124894 useragent:Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)
  65794 useragent:Hatena::Russia::Crawler/0.01
  58274 useragent:Ruby
  31493 useragent:Mozilla/5.0 (iPhone; CPU iPhone OS 15_4_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.4 Mobile/15E148 Safari/604.1
  29454 useragent:Mozilla/5.0 (compatible; AhrefsBot/7.0; +http://ahrefs.com/robot/)
  21492 useragent:Tiny Tiny RSS/21.11-7cfc30a (https://tt-rss.org/)
  20351 useragent:Slackbot 1.0 (+https://api.slack.com/robots)
  18765 useragent:Mozilla/5.0 (compatible; SemrushBot/7~bl; +http://www.semrush.com/bot.html)
  18395 useragent:Mozilla/5.0 (compatible; MJ12bot/v1.4.8; http://mj12bot.com/)
  17942 useragent:Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)

bingbot からのアクセスの方が Hatena::Russia::Crawler からのアクセスの 2 倍近くあった。ただし bingbot は検索エンジンのクローラーらしく、サイト全体をまんべんなくクローリングするような挙動で、特定の URL に一ヶ月間で数千回アクセスするような感じではない。

zcat -f log/access.log* | grep 'useragent:Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)' | cut -f5 | sort | uniq -c | sort -nr | head -25
    571 request_uri:/robots.txt
    352 request_uri:/
    205 request_uri:/category/misc
    160 request_uri:/2007/01/13/732
    156 request_uri:/2005/10/28/129
    150 request_uri:/2009/03/23/1010
    148 request_uri:/category/music
    146 request_uri:/archives
    144 request_uri:/category/www
    143 request_uri:/2016/07/
    143 request_uri:/2009/08/31/1074
    139 request_uri:/2010/07/05/1140
    138 request_uri:/category/photo
    138 request_uri:/2009/02/
    137 request_uri:/2006/09/09/658
    136 request_uri:/tags/netatmo
    136 request_uri:/2010/07/17/1145
    136 request_uri:/2006/07/23/611
    135 request_uri:/2014/03/
    134 request_uri:/?page=32
    134 request_uri:/2007/02/09/747
    133 request_uri:/category/shopping
    133 request_uri:/2021/07/26/how-to-get-to-kamikochi-from-fukuoka
    133 request_uri:/2011/11/03/finally-got-hhkpro2
    132 request_uri:/2006/01/

Hatena::Russia::Crawler は同一 URL に数千回もアクセスして何をしているのだろう？ 謎は深まるばかりだ。

最初にブログを作ったときからウェブサイトのタイトル（やロゴ画像）が h1 で、記事タイトルが h2 という見出しレベルで HTML を書いていた。しかし最近では、記事パーマリンクのページではサイトのタイトルなどには見出しレベルを設定せず、記事タイトルに h1 を当てている場合が多いようだ。なのでこのサイトでも記事タイトルを h1 とするように変えた。本文中の見出しレベルも h3 スタートだったのを h2 スタートに変えた。

伝統的なブログはインデックスページと記事パーマリンクページで HTML テンプレートを共通化している。なのでインデックスページに記事一覧を表示して h1 タグが並ぶとまずいということで記事タイトルは h2 から、という作りになってるような気がする。このサイトはインデックスページとパーマリンクページでのテンプレート共有化をほぼほぼやめたので、インデックスページとパーマリンクページで記事タイトルの見出しレベルを柔軟に変更している。

サイトの作り手からするとウェブサイトのタイトルこそが最も重要な要素でタイトルロゴなどを h1 でマークアップしたくなるのだが、読み手は Twitter やはてブから飛んできて刹那的に記事を消費し、インデックスページなんかには見向きもせずに去って行くだけだ。個別記事のタイトルこそ重要なのだ。

追記

r7kamura さんからこういうコメントをもらってこういう風に返信した。

あー、なるほど。文章の構造化と HTML の構造化は分けて考えるべき、ってのが HTML 5 の背景にありそうですね。僕はこの辺ごっちゃになってました。 article 内できちんと見出しが配置されてれば問題なさそうですね。

— morygonzalez (@morygonzalez) June 23, 2022

HTML5 が出てきたとき、個人的には何かめんどくさいなぁとしか思ってなかったし、世間は Flash を置き換える近未来技術みたいな評価をしていたと思う。しかし、 <header> タグや <article> タグによって、 HTML の構造化と文書の構造化を分離できるようになったのがセマンティックWeb的なメリットだということに気がついた。つまり <h1> などの見出しルールは <article> タグの中で守られていればよいのだ。

ということに HTML5 が死んでから気がついた。

どうしてHTML5が廃止されたのか | フューチャー技術ブログ

フロントエンド連載の5記事目です。 HTML5が2021年の1月に廃止されました。 Webエンジニアとしてバリバリ活躍されてる方やエグゼクティブテックリードのような肩書きを持つ方にとっては「何をいまさら」という話題かと思います。しかしながら、今年も新人さん入ってきてくださったので、プログラミングを学習中にHTML5という文字列に悩まされないように、そもそもHTML5とは何かや、廃止された経緯を

future-architect.github.io