$30 off During Our Annual Pro Sale. View Details »

公式ドキュメントとの正しい付き合い方+α

saku
November 11, 2023
45

 公式ドキュメントとの正しい付き合い方+α

九州学生エンジニア交流会LT

saku

November 11, 2023
Tweet

Transcript

  1. 自 己 紹 介 安達さくら/saku X: @SakuOnTheWeb 佐賀大学理工学部情報ネットワーク| B4 |

    SCLA University of Technology Sydney, Information Technology majorで1年間留学し てました 🇦🇺 Cybozu株式会社 | 24卒Frontend engineer | 内定者アルバイト   - kintoneのフロントエンドリアーキテクチャPJに携わって ます 普段はWebフロントエンドの世界に生息しています 🌟 フロントエンド周りの話をするの好きです
  2. そ ん な こ と 言 わ れ て も

    、 公 式 っ て 誰 . . . ? 俗にいう「公式ドキュメント」 OSSのGithubリポジトリ(Cloud系を除く) OSSコントリビュータの人(開発者の人)が出してる技術記事とか 個人的定義:“信憑性の高い”リソース
  3. 俗にいう「公式ドキュメント」 step by stepのGetting Started的なもの プレイグラウンド||APIの具体的な使用例||Syntax etc... OSSのGithubリポジトリ コードベースレベルの仕様、PR、Issue、Changelog/ リリー

    スノート etc... 変化の激しいフロントエンドではwatchしておくことも大事だったりする 👀 OSSコントリビュータの人が出してる技術記事 信憑性高めの「私だったらこう使うね」 技術に対するその人なりの見解・裏事情 得 ら れ る も の
  4. そ の 前 に . . . 個 人 的

    に 「 公 式 」 に 飛 び 付 か な く て も い い と 思 っ て る ケ ー ス 複数の技術を統合する解決策を探しているとき エラーが何を指すのかそもそもわからないとき 嫌いなタイプの公式ドキュメントのとき
  5. そ の 前 に . . . 個 人 的

    に 「 公 式 」 に 飛 び 付 か な く て も い い と 思 っ て る ケ ー ス 1️⃣ 複数の技術を統合する解決策を探しているとき 新しいものを生み出したい時にアイデア・技術的な解決策を 得たい時は外部リソースを参考にした方が早いケースが多い
  6. そ の 前 に . . . 個 人 的

    に 「 公 式 」 に 飛 び 付 か な く て も い い と 思 っ て る ケ ー ス 2️⃣ エラーが何を指すのかもわからないとき ドキュメントにエラーをいちいち詰めてる余地はない stackover flowやOSSのissueを見にいく
  7. そ の 前 に . . . 個 人 的

    に 「 公 式 」 に 飛 び 付 か な く て も い い と 思 っ て る ケ ー ス 3️⃣ 嫌いなタイプの公式ドキュメントのとき 個人的に好きなドキュメント以外の時( 👇好きなタイプ) 明確で短め コードブロックが各所に埋め込まれている example多め 願くばプレイグラウンド付き (tsのexampleがない)、なんかサイトの動作が悪い etc... 好きなタイプ e.g.; zustand、mdn etc...
  8. 公 式 に 苦 手 意 識 を も っ

    ち ゃ う 原 因 どこ読んでいいかわからん 何がどこに書いてあるかわからん それっぽいところ見てみたところで長い 長いのを頑張って読んでも明確な答えが見つけられない 見つけられても解決できない 😭 出てくる基礎的な単語がそもそもわからんくて離脱 MDN読んでる時にObjectってなんやねん、methodって なんやねんとなる 英語アレルギーあり・またはお使いの翻訳機にアレルギーあり
  9. 公 式 に 苦 手 意 識 を も っ

    ち ゃ う 原 因 - 個 人 で な ん と か し て も ら う も の ( I M H O ) どこ読んでいいかわからん 何がどこに書いてあるかわからん それっぽいところ見てみたところで長い 長いのを頑張って読んでも明確な答えが見つけられない 見つけられても解決できない 出てくる基礎的な単語がそもそもわからんくて離脱 英語アレルギーあり・またはお使いの翻訳機にアレルギーあり →ドキュメント読むための勉強の一部だと思って調べる! →with翻訳機で英語読めるくらいには!かかりつけ医にご相談を
  10. 公 式 に 苦 手 意 識 を も っ

    ち ゃ う 原 因 - 解 決 策 何がどこに書いてあるかわからん →ドキュメントの構造を掴む→(自分側)解決したい対象を明確に する→ドキュメントに戻る
  11. 公 式 に 苦 手 意 識 を も っ

    ち ゃ う 原 因 - 解 決 策 それっぽいところ見てみたところで長い →上から下に読むスキミングしながら読む、関係なさそうなとこ ろは一旦バッサリ「読まない」
  12. 公 式 に 苦 手 意 識 を も っ

    ち ゃ う 原 因 - 解 決 策 頑張って読んでも明確な答えが見つけられない 1:推測しながら読む「この人はつまり何を伝えたいんだろ う〜?」(理想は読み終わった後に一文要約できる) 2:例になりそうな箇所を見つける→具体的な実装をコードベー スを確認して得る -「例になりそうな箇所」:公式の「例」・codepenなど・Github で参考になりそうなリポジトリを検索
  13. 公 式 に 苦 手 意 識 を も っ

    ち ゃ う 原 因 - 解 決 策 見つけられても解決できない(一旦完全に理解したけど、なん か上手くいかん) - 公式が提示する条件と、自分が用意している条件の差異を列挙 - Getting started・他のリポジトリがどういった環境で動作している のか調査する - 内部構造を見にいく - それに関するIssueを見る - 解決策が取り入れられるものであれば適用 - なければIssueとして報告
  14. 今 日 伝 え た か っ た こ と

    🌟 読み方がわかれば公式は 格段に読みやすくなる!! 公式と正しく向き合って、快適なプログラミング・デバッグライフを 🏗️❤️