公開学習の利点

 (gilesthomas.com)
2 ポイント 投稿者 GN⁺ 2025-02-25 | 1件のコメント | WhatsAppで共有
  • 学びながら知った内容を要約やチュートリアルとして公開すると、自分が最初に学ぶときに必要だった記事を自分で作る効果がある
  • 新しい技術を学んで実際に試すだけで終わらず、文章で説明すると知識がより深く定着し、理解の抜けも見えてくる
  • epoll システムコールと edge-triggered/level-triggered イベントの違いは、ほぼ12年前に記事として残したあとも長く記憶に残っている事例である
  • Google Search Console によると、不定期訪問者のかなりの割合が学習整理記事に関連する検索語から流入しており、検索語と記事内容の一致度も高い
  • 今後は長文形式の学習記録を TIL deep dives という仮のカテゴリとして、短い Today I learned 記事とは別の形でより頻繁に投稿する予定である

最初に学ぶときに読みたかった記事を書く

  • 最近、いつもより多くブログを書き、アーカイブを読み返しながら、最も満足している記事の共通点を振り返った
  • 良い記事は、何かを学んだり仕組みを理解したりする過程で得た内容を要約し、ときにはチュートリアルとして構成した記事に近い
  • こうした記事は、「最初に学ぶときに自分が読みたかった記事」を自分で書くやり方である

文章にまとめると理解が強固になる

  • 新しく何かを学び、できれば自分で試してみることは、エンジニアとして成長するうえで重要である
  • 学んだ内容を文章にすると、知識がより深く定着する
  • きちんと理解したと言える基準は、知的で関心のある読者に説明できるかどうかにある
  • epoll システムコールと edge-triggered/level-triggered イベントの違いを扱った記事は、書いてからほぼ12年が経った今でも記憶に残っている

他の人にも届く学習記録

  • Google Search Console を見ると、定期読者ではない訪問者の多くが、こうした学習整理記事に関連する検索から流入している
  • 検索語と該当記事の内容がよく一致しており、訪問者は探していた情報を得られている可能性がある
  • 公開学習の記事は、個人の理解を固めると同時に、検索を通じて似た問題に直面している人にも届きうる

TIL deep dives という分類

  • 今後はこの種の記事をより意識的に増やしていく予定である
  • 「自分が学ぶ前に誰かに書いておいてほしかったチュートリアル」という表現は長すぎるため、暫定的に TIL deep dives という名前を付けている
  • これらの記事は、他のブログで見かける短い「Today I learned」投稿とは異なる
  • Simon Willison の TIL 記事のように同じ系統ではあるが、より長い形式の記事に近い

関連記事

1件のコメント

 
GN⁺ 2025-02-25
Hacker News の意見

  • そういう記事を見つけたなら、著者に知らせることもセットでやるべき行動だと思う
    短いメールを送るか、コメントを残せばいい。YouTube の有名人たちの陰には、良いコンテンツを投稿していながら、誰が見て感謝しているのかまったく知らない人が何千人もいる

    • 人々には肯定的なフィードバックがあまりにも足りない
      だから心を動かされた文章や作品を見たら、習慣として見知らぬ人にもメールを送っている。Derek Sivers と patio11 にならって、自分のサイトにも「常時招待」を目立つように掲げておいた。たまに「インターネット上の見知らぬ人からの挨拶」メールが来ると、その日やその週が良いものになる。ゆっくりしたペースの深い雑談には、メールが本当に向いている
      https://www.evalapply.org/index.html#standing-invitation
    • ある人が、1999 年式 Honda Civic の壊れた車載ソケット、つまりシガーソケットの直し方を投稿していた
      グローブボックスの下に小さなトランジスタのような部品があるなんてまったく知らなかったし、50 セントで直る修理だった。その人が投稿していなければ絶対に知らなかったはずで、お礼のメッセージを送った
    • 以前、2000 年代初頭のコンピューター雑誌のデモディスクで見たゲームデモをもう一度遊びたくて、開発者を探してメールを送ったことがある
      実はそのゲームは正式リリースされたことがなく、複数のゲームやソフトウェアと一緒に収録されたデモだけが唯一の公開された痕跡だった。開発者はまだインストーラーを持っていて、返信に添付できるほど小さかったので送ってくれた。20 年以上前に作ったゲームについて尋ねられたことで、その人の一日がかなり良いものになったのではないかと強く感じた
    • こういうことは自分にも 3〜4 回あったが、そのたびに一週間が良いものになった。強くおすすめする

  • 自分の TIL 記事の基準もこの哲学と同じだ
    先に検索したにもかかわらず、ある問題を把握するのに何時間もかかったなら、それは記事として残す価値があるという非常に強いサインだ。最近の記事は、GitHub Actions のスクレイピングトラフィックを Tailscale 出口ノード経由でプロキシする内容だ: https://til.simonwillison.net/tailscale/tailscale-github-act...

    • 本文でもすでにそう言っている
      「Simon Willison はこれが本当にうまく、TIL 用のサブドメインまで持っている」という内容だ

  • 何かを直したり問題に苦労したりするたびに、いつも自分のためにブログ記事を書き、解決策を組み立てる過程で検索した正確なエラーメッセージや検索キーワードをできるだけ入れておく

    • 2 日前、新しいコンピューターの NixOS で Gamescope を動かす方法を探していた
      検索していると関連する Reddit の投稿を見つけ [1]、そこに GitHub Gist が付いているのを見た後、それを投稿したのが自分だったと気づいた。すでにやっておいた作業だったことを完全に忘れていた
      [1] https://www.reddit.com/r/NixOS/comments/1dahr3g/steamos_base...
    • 自分の最も役に立っている Stack Overflow の回答は、実は自分が何をしているのかほとんど分かっていなかった頃に書いたものだ
      MVC.net 関連の問題で、質問と同じ問題は直せたものの、「ベストアンサー」と表示されていた回答が何を意味しているのか、なぜ関係があるのか理解できなかった。そこで「ここをクリックして、あそこに合わせてこれを入力した」というように、自分が直した手順を書いた。ずっと後になって、自分の回答は結局ほかの回答がやれと言っていたことそのものだったと分かったが、Visual Studio が作るバインディング、ビュー、部品の間の魔法のようなつながりをまだ理解しないまま検索していた多くの人たちから、自分の回答は票をもらい続けた
    • 自分もそうしている
      最後に書いた記事は、ベビーモニターのバッテリーを交換する方法を突き止めようとした内容だった
      https://www.michael1e.com/how-to-replace-the-eufy-spaceview-...
    • 自分もこうしているが、Grok や ChatGPT のようなLLM 権威者たちにやられたとき、どう対応すべきかはまだ分からない
      彼らはトラフィックや報酬を返してくれるわけでもなく、出典として引用すらしない ¯_(ツ)_/¯
    • 質問を投稿するときも同じように、自分が検索したものをすべて入れておくとよい
      そうすれば回答が付いたとき、次の人が見つけられる

  • このやり方でおそらく最も重要なのは、自分が見つけたかった記事を自分で書けば、後でいつか自分にまた役立つ可能性が高いという点だ
    自分が書いた多くの記事は、公開から何年も経っても再び役に立った。サイトに検索機能を付け、マイクロブログの記事まで含めるようにしてから、その効果はさらに大きくなった

    • 文章にしておく行為自体が、記憶に定着させる助けになる
      たまに検索していて、自分の古いブログ記事を見つけたこともある
    • ワークステーションを消して再インストールするたびに、Arch に Ubiquiti 管理アプリをインストールする手順をいつも忘れてしまう
      2019 年にその内容をブログに書いておいたので、今でもそれを見て思い出している

  • この習慣は自分にとって生活密着型のビジネスになった。今はドイツの官僚制度を文書化して生計を立てている
    「なぜやるのか」について発表し、それが長いブログ記事になった: https://nicolasbouliane.com/projects/all-about-berlin
    もっと多くの人がこうしてくれればいいと思う。似たような資料に出会ったら、意識して感謝を伝えている。ひとつは韓国を自転車で横断するのに役立ち、もうひとつは非常に特定の装置を直すのに役立った。Google、ソーシャルメディア、AI がこうした役に立つ人たちの仕事を露天掘りのように持っていき、報酬を奪っているのは残念だ

  • 情報がなかったため、何日もかけて調べ上げた内容をまとめたウェブページを近日中に公開する予定
    実際の公開が遅れているのは、以前より持続可能なやり方でやってみようと実験しているから。どうにか収益を作ることや、「AI」クローラーやサービスに丸ごとコピーされにくくすることも含まれる :(

  • 誰かが、文章を書くこと、料理、ツール開発といった自分の作業を楽しむために時間を割いてくれると、認められた気がして一気に気分が上がる
    逆に、何かを出したのに虚空へ消えていき、誰にも気づかれず祝われもしないと力が抜ける。Mediumアカウントを10年運営する中でその両方を経験したし、今では書くこと自体が自分の旅で、読者は気まぐれなものなので、やめることはできない。これが創作の利用規約のようなものだと受け入れている

    • 自分のブログの普通の記事にはコメントが付かない
      平均するとたぶん1件くらいだと思うが、コメントが付く記事にはたいてい3〜4件付くからだ。19年のブログ歴で最大のドーパミンは、この記事がHNのトップページで1位になったのを見たときで、またそんなことが起きるとは思えない

  • 今もそういうブログ記事を1本書いているところ
    ここ数カ月は、自分の領域であるKubernetesで苦労して突き止めたことや、オープンソースのコードベースを読むことをかなり深く掘り下げる記事だけを投稿している

  • この話題は核心を突いていて、こういう記事を書かなければという欲求が日に日に強くなっている。とにかくやるしかない
    最近 Microchip PolarFire SoC[1] を触っているが、FPGA設計方面の資料が多くないことはすでに分かっていた。だがMicrochipは、Xilinx/AMDやLattice、オープンソースツール界隈とはまた別の次元だ。何かを成し遂げるために本当に多くの戦いを重ね、ようやくある程度の作業フローができ、チップも理解できるようになってきた。今ではかなり気に入っていて、ハードウェア・ソフトウェア協調設計に入りたい人にとっては、予算内で試せるチップだと思う
    毎回戦いを終えるたびに、「くそ、これはどこかのブログに書いておくべきだ。未来の誰か1人、いや未来の自分1人を助けられるだけでも大勝利だ」と思う。だがこれまでは、怠け者で少し怖がっている自分が勝っていた
    英語が母語ではないので十分うまく書けなかったらどうしよう、自分が書くことは皆にとっては当たり前で、自分だけが苦戦していたのだとしたらどうしよう、友人が偶然見て笑ったらどうしよう、と思っていた。それでも構わない。自分がやりたいのだから、やるべきだ
    [1] https://www.microchip.com/en-us/development-tool/mpfs-disco-...
    最後の言葉でCharles Bukowskiの「Roll the dice」を思い出した。これをもう少し頻繁に思い出すべきなのかもしれない: https://hellopoetry.com/poem/68266/roll-the-dice/

  • 最近は、自分が書きたかった記事をすでに誰かが書いていることがいつもある。だから自分のバージョンを書く
    初期のブログ記事の大半は、公開フォーラムの質問に触発されたものだった。そこで回答し、あらためてブログ記事を書き、その後はその記事のリンクを送る、という流れだった。2000年代初めの自分のブログ記事にはその痕跡が残っている
    たとえばIE5でブラウザを全画面で開く方法の記事は大成功だった: https://brajeshwar.com/2002/ie-50-full-screen-from-itself/