Practical Tutorialsのプロジェクトベース学習が再び注目を集めるも、リポジトリ自体は変わらず

Practical Tutorialsは、急増の背景に明確な新リリースや最近の変更が見当たらないにもかかわらず、約26万7,000スターを獲得してGitHub Trendingに戻ってきた。同社のproject-based-learningリポジトリは、実際のソフトウェア構築を軸に整理された実践的チュートリアルを求める開発者の関心を再び集めている。

この注目は実在するものだが、その意味には留保が必要だ。入手可能な証拠が確認しているのは、2026年8月12日時点での再びの可視化であり、新たに公開された製品、カリキュラム、研究成果ではない。

このリポジトリの公開履歴が、中心的な対立を生み出している。GitHubには巨大な需要と数百件の提案されたコントリビューションが示される一方、表示されるmasterブランチの履歴は2023年3月21日のコミットで終わっている。

そのため、これは単なる人気リンク集以上の存在だ。編集上の保守が大幅に遅れている状況でも、コミュニティでの評判が教育カタログの有用性を維持できるかを試す事例となっている。

この負担は学習者とメンテナーの双方にかかる。学習者は長く使えるプロジェクトと古くなった依存関係を見分ける必要があり、メンテナーは増え続けるリンク、修正、追加提案のキューに直面している。

Practical Tutorialsが再び注目された実際の理由

確認された出来事はGitHub Trendingへの再登場であり、Practical Tutorialsによる新リリースではない。

BettaFishのGitHub Trendingスナップショットでは、practical-tutorials/project-based-learningが現在の注目リストで16位に置かれていた。このアグリゲーターは、検証済みの公開時刻を付与しておらず、何の活動が順位を押し上げたのかも説明していない。

GitHub Trendingは従来型のニュース発表ではなく、発見のシグナルだからこそ、この区別は重要だ。リポジトリは新たなスター、外部での共有、再燃した議論、あるいは別のコミュニティ関心の高まりによって浮上することがある。

GitHubの公開ページは、このプロジェクトをプログラミングチュートリアルのキュレーション集として説明している。各チュートリアルは、アプリケーションをゼロから構築する手順を学習者に案内し、エントリーは主にプログラミング言語ごとにまとめられている。

リポジトリのカタログは、C#、CとC++、Clojure、Dart、Elixir、Erlang、F#、Go、Haskell、Java、JavaScript、Kotlin、Python、Rustなどの言語を網羅している。Webアプリケーション、ゲーム、ネットワーキング、機械学習、モバイル開発、開発者ツール向けのリソースも掲載している。

この出来事を確認した時点で、GitHubには約26万7,000スター、3万4,700フォーク、151件の未解決issue、153件のオープンなpull requestが表示されていた。これらの数値は継続的に変動するため、日付付きのスナップショットとして扱うべきだ。

このリポジトリはMIT Licenseを採用しており、フォークやガイドラインに沿ったコントリビューションを促している。ホスト型の学習プラットフォームや完成済みソースプロジェクトの集まりではなく、主として索引である。

この形式が、広く利用される理由の一部を説明している。開発者は1つの文書を見渡し、言語を選び、天気アプリケーションからインタープリター、ネットワークスタックまで幅広いプロジェクトを見つけられる。

しかし、この形式は責任を外部の公開者へ移すことにもなる。チュートリアルは個人ブログ、動画プラットフォーム、アーカイブされたWebサイト、あるいは無関係な著者が管理するドキュメントページに置かれている場合がある。

メンテナーが8月12日に大規模な更新を発表したという検証済みの証拠はない。また、このTrending掲載に特に結び付く検証済みのスター増加数も存在しない。

したがって読者は、この順位を突然の製品導入の証拠と見なすべきではない。これは、このリポジトリが目立つ発見チャネルに再び現れるのに十分な現在の関心を集めたことを示している。

以前の可視化は、これが繰り返されるパターンだという見方を支えている。トレンド追跡サービスは、このリポジトリが以前にもGitHub Trendingに到達したことを記録しており、2023年12月には1位になったとの報告もある。

今回の掲載は、異例に古く、異例に大きい教育インデックスに再び関心を向けた点で、なお注目に値する。より示唆に富む話は、この人気を保守記録と比較したときに始まる。

Practical Tutorialsのトレンドは需要のシグナルだ

開発者が探しているのは単に説明の増加ではなく、実際に構築できる具体的な対象である。

このリポジトリは、シンプルな学習の約束から始まる。言語を選び、アプリケーションを選び、そのアプリケーションをゼロから構築するチュートリアルに従う、というものだ。

この約束は、個別の構文やフレームワーク機能を中心に整理されたドキュメントとは対照的である。コンパイラー、チャットアプリケーション、デバッガー、ゲーム、API、データベースを使うサービスなど、学習者に到達点を与える。

カタログの人気は、掲載されたすべてのチュートリアルが効果的に教えていることを証明するものではない。GitHubスターは、ブックマーク、支持、個人の読書キュー、あるいは単純な関心を示している場合がある。

リポジトリへのスター付与に関する研究では、ユーザーが異なる理由でスターを付けることが示された。著者らは、スター数をソフトウェア品質や実世界での利用の単純な尺度として扱わないよう警告している。

この警告は、ここにも直接当てはまる。約26万7,000スターは並外れた認知度を示すが、完了率、学習成果、リンク品質、学習者の満足度は明らかにしない。

それでも、この構造は確立された教育的な考え方に合致している。プロジェクトベース学習では、継続的な課題に取り組む、または具体的な成果を生み出す過程で、学生が知識を身に付ける。

プログラマーにとって、その成果は厳しいフィードバックループをもたらす。アプリケーションはコンパイル、実行、入力受け付け、データ保存、ネットワーク越しの通信、または意図したインターフェースの表示を行わなければならない。

構文のレッスンは短い演習の後で完結したように感じられることがある。実際のプロジェクトは、セットアップ、アーキテクチャ、デバッグ、テスト、ドキュメント、デプロイの間にあるつながりを露わにする。

2024年の計算論的思考に関するメタ分析は、プロジェクトベース学習を含む31件の実験および準実験を統合した。その結果、学生の計算論的思考の発達との間に全体として肯定的な関係が見いだされた。

この証拠が裏付けるのは広範な手法であり、この特定のGitHubリストの品質ではない。このリポジトリは、共通のカリキュラム、評価モデル、指導者、統制された学習環境を提供していない。

各エントリーの違いも大きい。電卓を作ることは、エミュレーター、プログラミング言語インタープリター、TCP/IPスタック、分散アプリケーションを書くことよりも、限定された課題である。

そのため、このコレクションの実践的チュートリアルは、同等の学習単位ではなく出発点として機能する。学習者は依然として、前提知識、範囲、想定所要時間、そしてチュートリアルが現在のツールと互換性を保っているかを判断しなければならない。

コーディング支援を得やすくなるにつれ、この必要性は高まっている。AIアシスタントは説明やコード断片を生成できるが、学習者には、それらの断片が一緒に機能するかを試す一貫した課題がなお必要だ。

プロジェクトはその制約を生み出す。アシスタントとの自由形式の会話を、観察可能な技術的判断の連続へと変える。

このトレンド入りしたリポジトリは、開発者教育の分断も反映している。有用な教材はブログ、動画、書籍、ドキュメントサイト、アーカイブされた個人プロジェクトに分散している。

キュレーションされた索引は、発見にかかる作業を減らす。どのチュートリアルが存在するかを尋ねる代わりに、学習者は現在の能力と好む言語にどのプロジェクトが合うかから考え始められる。

この発見上の利点は、古いリポジトリが新機能を公開せずともTrendingに戻れる理由の説明になる。その価値はリリース頻度だけでなく、集約と分かりやすい整理にある。

したがって最も強い解釈は、満たされていない需要に関するものだ。より新しい学習ツールが即時の回答を約束していても、開発者は受動的な閲覧から完成したソフトウェアへ至る信頼できる道筋を依然として求めている。

より弱い解釈は、この順位がすべてのリンクとレッスンを正当化するというものだ。GitHub Trendingにその審査はできず、スター数もそれに代わるものではない。

人気が保守を先行している

このリポジトリの中心的な緊張は、現在の需要と老朽化した編集レイヤーとの隔たりにある。

GitHubに表示されるコミット履歴では、masterブランチの最新コミットは2023年3月21日となっている。この変更では、OCamlでGame Boyエミュレーターを書くチュートリアルが追加された。

それに先行する複数のコミットは2023年3月と2022年8月に行われた。そこではCとC++のプロジェクト、Flutterの教材、Djangoチャットアプリケーションが追加されている。

さらに以前の保守作業では、リンク切れのチュートリアルを削除し、古くなった参照を修正していた。これらのコミットは、リンクの健全性が長らくリポジトリの編集上の負担の一部だったことを示している。

履歴が古いからといって、すべてのチュートリアルが使えないわけではない。パーサー、ネットワーキング、アルゴリズム、基本的なWeb概念に関わる基礎的なプロジェクトは、何年にもわたって学習に役立ち得る。

ただし、トレンド入りしているからといって、この索引が最新だと見なすことはできない。フレームワークのバージョン、パッケージマネージャー、デプロイサービス、ブラウザーAPI、ホスト型依存関係は、基礎的な概念よりはるかに速く変化する。

いくつかのタイトルは、この問題を直接示している。カタログには、古いAngularリリース、歴史的なフレームワークバージョン、所有者や製品方針が変わったサービスを中心にした教材が含まれている。

古いチュートリアルに従う学習者は、存在しないパッケージ、非推奨のコマンド、互換性のないランタイムバージョン、あるいはスクリーンショットと一致しなくなった認証フローに遭遇する可能性がある。

こうした失敗は、ときに価値あるデバッグスキルを教えてくれる。しかし、プロジェクトが本来の学習目標に到達する前に、初心者を行き詰まらせることもある。

このプロジェクトの153件のオープンなpull requestも、もう1つの重要なシグナルである。コントリビューターは新しいリソースや修正を提出する意思があるように見えるが、このキューはコミュニティからの入力と編集上の受け入れが同じ速度で進んでいないことを示している。

オープンなpull requestが自動的にマージ可能というわけではない。一部の提出は既存教材と重複していたり、低品質なコンテンツを宣伝していたり、コントリビューション規則に違反していたり、広範な検証を要したりする可能性がある。

それでも、この規模のキューはトレンドの解釈を変える。ボトルネックは候補となる教材の不足ではなく、それらをレビュー、分類、検証、保守するために必要な作業だ。

この作業は、リンクリポジトリでは特にコストが高い。コード変更は自動テストで確認できることが多い一方、チュートリアルには正確性、明確さ、範囲、教育的価値にまたがる人間の判断が必要になる。

リンクチェックはページの欠落を検出できるが、手順が今も約束された結果を生み出せるかどうかは判断できない。また、初心者がコードを理解するのに十分な文脈を受け取れるかも、確実には評価できない。

リポジトリが幅広い言語を扱っていることも問題を増幅させる。PythonのWeb開発に詳しいメンテナーが、OCamlのエミュレーターや最新のSwiftアプリケーションを評価する資格を持つとは限らない。

コミュニティによるキュレーションは、その専門知識を分散できるが、それは所有権とレビューの経路が活発である場合に限られる。そうでなければ、コントリビューションは公開カタログを更新しないまま蓄積していく。

ここでリポジトリの古さは、利点であると同時に負債にもなる。長寿であることは、新しいカタログにはすぐ再現できないバックリンク、認知度、蓄積された幅広さをもたらす。

同じ履歴は古い前提も残す。定期的なレビューがなければ、評判によって老朽化した教材が実際より安全に見えてしまう。

開発者は注意力が限られているため、最初の絞り込みとしてGitHubでの人気をよく利用します。スター数の多いリポジトリは、先週まとめられた無名のリストよりもリスクが低く見えます。

この近道は発見には役立ちますが、最終的な選定には不十分です。学習者は依然として、公開日、コメント、依存関係のバージョン、リンク先のソースコード、最近の利用者報告を確認する必要があります。

社内でこうしたプロジェクトを勧めるチームも、同じ問題に直面します。オンボーディングに使うリストには、週末に見つけた興味深いプロジェクトを個人的に集めたものよりも厳密なレビューが必要です。

エンジニアリングマネージャーは、1つのチュートリアルを選び、動作する環境を固定し、テストを追加し、既知の修正方法を文書化できます。そうすることで、外部リンクを管理された学習演習へと変えられます。

個人には、同じプロセスのより軽量な版が必要です。数日を費やす前に、スターターファイルが読み込めること、主要な依存関係を引き続き入手できることを確認すべきです。

したがって、このトレンドはメンテナーに対し、リポジトリの現在の運用モデルを明確にするよう求めています。同時にユーザーにも、人気を保守の保証として扱わないよう促しています。

プロジェクトベース学習にも足場が必要

プロジェクトは文脈を与えますが、順序立った学習、フィードバック、信頼できる指導を自動的に与えるわけではありません。

このリポジトリの形式は自律性を重視しています。学習者は項目を選び、GitHubを離れ、外部の著者が提示するプロジェクトへの道筋をたどります。

この自由度は、すでに自分の環境を理解している開発者には有効に働きます。チュートリアルが壊れた場合でも、古い手順を修正し、パッケージを置き換え、一次ドキュメントを参照できます。

初心者が直面する課題は異なります。自分のコードのエラーと、チュートリアル、OS、パッケージのバージョン、外部サービスに起因するエラーを見分けなければなりません。

この診断負荷は、学習そのものを圧倒しかねません。アプリケーション構造を学ぶつもりだった学生が、文書化されていないインストール競合の解決に何時間も費やすことがあります。

研究は、プロジェクトベースの手法を支持しつつ、実装には慎重であるべき理由を示しています。教育成果は、プロジェクト設計、支援、事前知識、評価、振り返りの機会に左右されます。

2021年の系統的レビューは、年少の学生を対象とした統制下のプロジェクトベース学習研究を検討しました。利用可能な研究全体で、結論は明確でなく、方法論上の大きな弱点も見られたとしています。

この対象集団は、自主的に学ぶ成人プログラマーとは異なります。ただし、このレビューが示すより広い警告は依然として有用です。活動を「プロジェクトベース」と呼ぶだけでは、その有効性は証明されません。

チュートリアルは、受動的な模倣の別形態になり得ます。学習者は意味のある設計判断を下したり、各コンポーネントが存在する理由を理解したりせずに、講師のコードを1行ずつ再現するかもしれません。

完成したインターフェースは、習熟したという錯覚を生み出し得ます。その錯覚は、学習者が要件を変更し、未知のバグを修正し、チュートリアルなしでアーキテクチャを説明しなければならないときに明らかになります。

効果的な実践チュートリアルには、模倣を中断させる場面が必要です。有用な演習は、挙動を予測する、実装を選ぶ、テストを書く、失敗を調査する、完成したシステムを拡張するといったことを学習者に求めます。

このリポジトリは、すべての項目に同一の基準を適用しているわけではありません。役割はキュレーションであるため、教育設計は各リンク先の著者に委ねられています。

そのため、避けられないばらつきが生じます。あるチュートリアルはトレードオフやテストを丁寧に説明する一方、別のチュートリアルは視覚的に分かりやすい成果を素早く実現することに重点を置くかもしれません。

プロジェクト選定は、どのスキルに注意が向くかも決定します。よく知られたアプリケーションのクローンはインターフェース構築を教えられる一方で、アクセシビリティ、セキュリティ、可観測性、デプロイ運用を省くことがあります。

プロトコル実装はシステム理解を深めるかもしれませんが、プロダクト要件を扱う練習はほとんど得られません。機械学習のデモは、データ品質や評価を教えなくても正常に動作することがあります。

したがって学習者は、プロジェクト名をカリキュラムではなく境界として扱うべきです。「チュートリアルを完了する」以外の明確な目標が必要です。

目標の1つは、完了後に中核要件を変更することかもしれません。別の目標として、ライブラリを置き換える、失敗処理を追加する、各アーキテクチャ上の依存関係を説明することが考えられます。

テストも別の境界を提供します。元の実践チュートリアルにテストがなければ、小規模なテストスイートを書くことで、学習者がアプリケーションの挙動を理解しているかを確かめられます。

AIコーディングアシスタントは、新たな複雑さを加えます。セットアップの障害を取り除き、未知のコードを説明できますが、もっともらしいパッチを生成することで知識のギャップを隠すこともあります。

最も安全な使い方は、診断と比較です。学習者は複数のアプローチを求め、一次ドキュメントを確認したうえで、最終的な選択を自分のノートで正当化できます。

長期プロジェクトでは、こうした決定を検索可能な状態に保つことに価値があります。開発者は技術ナレッジベースを使い、チュートリアルの手順をエラー、ドキュメント、設計判断と結び付けられます。

この記録は、コピーした手順を追跡可能な学習プロセスへと変えます。また、途中で中断しても、過去の推論を何度も再構築せずに学習を再開する助けになります。

このリポジトリがTrendingに再登場したからといって、プロジェクトと基礎の誤った二者択一を復活させるべきではありません。強いプロジェクト学習は、学習者を構文、アルゴリズム、ドキュメント、理論へと繰り返し立ち返らせます。

より適切な区別は、消費と能動的な構築の間にあります。実践チュートリアルは、より長いコピー手順を提示するのではなく、判断、フィードバック、改訂を生み出すときに役立ちます。

このリポジトリはAI生成ガイダンスと競合している

Practical Tutorialsは即時の個別最適化された回答と競合していますが、キュレーションされたプロジェクトの境界はAIシステムが置き換えにくいままです。

このリポジトリが2017年に始まった時点では、一貫したゼロから構築するシリーズを見つけることは大きな発見の課題でした。検索結果は、関連する資料を無関係な投稿に分散させることが多かったためです。

現在では、AIアシスタントがこの発見コストを下げています。学習者は、好みの言語、OS、フレームワーク、経験レベルに合わせたカスタムのプロジェクト計画を依頼できます。

アシスタントは、エラーのたびに説明を調整することもできます。静的なチュートリアルは、学習者のパッケージマネージャーが予期しないメッセージを返しても対応できません。

これは、キュレーションされたリンク集に現実的な圧力をもたらします。古いページを列挙するだけのカタログは、現行の手順を即座に生成するアシスタントほど便利ではありません。

しかし、生成されたガイダンスには別の検証問題があります。アシスタントは、存在しないAPIを提案したり、互換性のないバージョンを組み合わせたり、後で重要になる要件を省略したりする可能性があります。

公開されたチュートリアルは、安定した成果物を提供します。他のユーザーはそれにコメントし、コードをフォークし、破損を報告し、自分の結果を著者の出力と比較できます。

practical-tutorialsコレクションは、社会的なフィルタリングをもう1層追加します。現在のレビューの強度には差があるとしても、各リソースは誰かによって掲載対象として選ばれています。

したがって主要な競争相手は、特定の教育会社やアシスタントではありません。持続性のあるコミュニティキュレーションと、オンデマンドで生成される個別ガイダンスとの競争です。

コミュニティキュレーションは持続性と検証可能性を提供します。生成されたガイダンスは適応性と速度を提供します。

どちらの経路も、信頼を単独では解決しません。古いチュートリアルはエコシステムの変化により誤っている可能性があり、新しいAIの回答は推論や情報源への根拠付けに失敗しているため誤っている可能性があります。

このリポジトリの最も強い役割は、プロジェクトマップとしての役割です。多くの言語にわたり、学習者に具体的な到達点と構築可能なものの例を示します。

その後、アシスタントが選んだ経路の案内を支援できます。コンパイラ出力を説明し、古いコマンドを置き換え、テストを提案し、最新のドキュメントを見つけられます。

この組み合わせたワークフローは、意味のあるプロジェクト境界を維持しながら、応答性のある支援を加えます。また、アシスタントがまったく検証されていないカリキュラムを自由に作り出す余地も制限します。

弱点は依然として情報源の古さです。アシスタントがチュートリアルの手順を修復しても、コースの残りを保証するわけではなく、一見成功したパッチが意図された学習内容を変えてしまう可能性があります。

学習者は、修復と再設計の区別を保つべきです。主要な手順のすべてに置き換えが必要なら、そのチュートリアルはもはや信頼できる道筋を提供していません。

メンテナーは、生成されたリストでしばしば欠けるメタデータを強調することで対応できます。最終レビュー日、テスト済みランタイムバージョン、難易度、想定規模、アーカイブ済みの状態は、より安全な選定につながります。

また、基礎的なプロジェクトとフレームワーク固有のアプリケーションクローンを分けることもできます。基礎教材は異なる形で古くなるため、同じ鮮度の期待を共有すべきではありません。

コンパイラのチュートリアルは、概念上の対象が安定しているため、ツールが古くても価値を保てます。クラウドデプロイのチュートリアルは、1つのプロバイダーがインターフェースを変更しただけで不正確になる可能性があります。

現在のリポジトリは、こうした違いを一貫して伝えていません。言語別の構成は閲覧には役立ちますが、教育品質や保守リスクについてはほとんど明らかにしません。

GitHub自体は、コミット、issue、pull requestといったシグナルを提供します。しかし、それらのシグナルはインデックスを説明するものであり、必ずしも外部でホストされる各チュートリアルを示すものではありません。

このことは、人気が見込み学習者に伝えられる内容を制限します。このコレクションは有名ですが、その知名度は、実際に学習が行われるリソースの1段階上にあります。

その再浮上は、人によるキュレーションされた発見が消えていないことを示します。むしろAIによって、基本的な列挙が安価になったため、カタログの編集基準はより重要になっています。

差別化を維持するには、このコレクションは信頼できる選定と持続的な構造を提供しなければなりません。そうでなければ、学習者は類似したプロジェクトリストを数秒で生成できます。

トレンドの持続を左右する3つのシグナル

次の章は、保守活動、より明確な鮮度シグナル、そして学習者がブックマーク以上の形でキュレーションされたプロジェクトを使い続けている証拠に左右されます。

最初のシグナルは、pull requestキューの動きです。レビュー済みマージが継続的に行われれば、再び集まった注目がスターだけでなく編集能力を生み出していることを示します。

そのマージの内容は、単純な件数より重要です。デッドリンクの削除、バージョン更新、重複の整理、より明確な分類は、リポジトリ最大のリスクに直接対処します。

無差別な追加が一時的に増えるだけでは、証拠として弱いでしょう。リンクが増えると選択肢は増えますが、検証とナビゲーションは難しくなる可能性があります。

2つ目のシグナルは、リソースごとの保守メタデータの導入です。最終レビュー日やテスト済みバージョンのフィールドがあれば、学習者は安定した概念と環境依存の手順を区別しやすくなります。

アーカイブ済みや古くなった項目も、現行であるかのように見せずに表示し続けられます。このアプローチは、古い手順への意図しない依存を減らしつつ、歴史的価値を保ちます。

難易度や前提条件のラベルも、プロジェクト選定を改善します。ただし、古いコミット履歴が目立つカタログがこのトレンドで再び注目を集めたため、より緊急なのは鮮度の問題です。

3つ目のシグナルは、Trending掲載が薄れた後も注目が続くことです。短期間の発見の波で得たスターは到達範囲を示す一方、フォーク、issue報告、完成後の拡張、保守される派生プロジェクトは、より深い利用を示します。

完了度を完璧に測る公開指標はありません。それでもGitHub上の活動は、学習者や教育者がこのインデックスを実際に動くプロジェクトへと変えているかを示し得ます。

新たな保守がないままリポジトリがTrendingから消えれば、この出来事は再発見のもう1つの循環に見えるでしょう。評判は大きいままでも、鮮度のギャップは解消されません。

寄稿者がレビュー待ちのキューを減らし、明確な最新性の指標を公開すれば、この出来事は別の意味を持つことになる。それは、注目が価値ある公共リソースを再び動かすことに成功した証しとなる。

より広い教訓は、ほかの教育向けリポジトリにも当てはまる。検索での可視性は、元来のメンテナンスのリズムが鈍化した後も、インデックスを存続させ得る。

この持続性は、有用でもある。優れた教育コンテンツには、決まった有効期限がないからだ。一方で、人気によってリンク切れや古い環境が見えにくくなる危険もある。

学習者は、リポジトリ全体の刷新を待つ必要はない。一つのプロジェクトを選び、依存関係を確認し、拡張内容を定め、公開後に何が変わったかを記録すればよい。

教育者やエンジニアリングチームは、さらに踏み込める。選定したチュートリアルをテストし、環境を固定し、レビューのチェックポイントを加え、参加者が完成したシステムを変更できるかを測定できる。

こうした手順により、実践的なチュートリアルは、元のカタログがすべての教育要素を提供していると仮定せずとも、構造化された課題へと変わる。

したがって、現在の傾向は、注意書きを伴う需要シグナルとして読むべきだ。開発者は依然として、動作するソフトウェアで終わる学習パスを重視している。しかし、発見は最初の層にすぎない。

このリポジトリにとって次に意味を持つ出来事は、また一時的に順位を上げることではない。その膨大な利用者と蓄積された貢献のバックログが、より最新で、より透明性の高いカタログを生み出したという証拠である。

それまでは、実践的なチュートリアルは、検証済みのカリキュラムではなく、有用な入口であり続ける。一つのスキルを伸ばせるプロジェクトを選び、まず環境を確認し、元の手順には示されていないものを作ろう。