今週、小さなものをリリースする
スコープからデプロイまで、学習だけで終わっている状態から抜け出して、今週中に動作する小さなプロジェクトをリリースするための具体的な計画。
チュートリアルループから抜け出せない人のほとんどは、スキルに問題があるのではなく、リリースができていないのが問題です。Python のコンテンツを 40 時間見ても、自分で何かを作ろうと座った瞬間に凍り付いてしまいます。それはチュートリアルがあなたのすべての判断を取り除いてくれるからです。このガイドは強制的な仕組みです:小さなものを選んで、完成させて、誰かの前に出す、今週中に。
週末で完成できるプロジェクトを選ぶ
ここでの失敗のパターンはスコープです。人々は最初のプロジェクトが認証、課金、ダッシュボードを持つ SaaS アプリであるべきだと決めます。それは週末プロジェクトに偽装した 6 ヶ月プロジェクトです。
代わりに、単一の明確な機能を持つものを選んでください:
- EXIF 日付に基づいてフォルダ内のファイルをリネームする CLI ツール
- パブリック API をスクレイピングして毎日のサマリーをメールで送るスクリプト
- 1 つのフォームと 1 つの出力ページを持つ Flask アプリ
- 訪問したどのページでもキーワードをハイライトするブラウザ拡張
コードを書く前に、スコープを 1 文で書き出してください。その文に「and」が 2 回以上必要なら、削ってください。「支出を追跡し、また分類し、またチャートにするツール」は 3 つのプロジェクトです。まずトラッカーをリリースしてください。
本当の締め切りと本当なオーディエンスを設定する
結果を伴わない締め切りは締め切りではありません。友人に伝えるか、Discord サーバーに投稿するか、金曜日に同僚にデモを見せることにコミットしてください。オーディエンスは締め切りより重要です。実際に誰かがそれを見るということを知っていることは、あなたがどのようにそれを構築するかを変えます。アーキテクチャを過度に磨くのをやめて、ハッピーパスが実際に機能することを確認し始めます。
数字を与えてください、空気感ではなく。「時間があるときに取り組む」は何も生み出しません。「今夜 2 時間、明日 2 時間、土曜朝にリリース」はプロジェクトを生み出します。
最初にダサいバージョンを作る
フォルダ構造の議論をスキップして、CSS フレームワークの選択をスキップして、40 行を保存するツール用に Postgres と SQLite を選択することをスキップしてください。1 つのファイルを書いてください。ロガーの代わりに print() ステートメントを使用してください。データベースが必要な場合は、Python リストを使用してください。
# expenses.py - ugly version, and that's fine
import csv
from datetime import date
def add_expense(amount, category):
with open('expenses.csv', 'a', newline='') as f:
writer = csv.writer(f)
writer.writerow([date.today().isoformat(), amount, category])
add_expense(12.50, 'coffee')
これは動作する支出トラッカーです。スケーラブルではなく、テストがなく、明日実際に使用できるものまで 90% の道のりを進むことができます。動作するダサいものはリファクタリングできます。存在しない美しいものはリファクタリングできません。
どこかにデプロイする、たとえ下手であっても
ノートパソコン上のプロジェクトはリリースとしてカウントされません。インターネットの前か、人が自分自身で実行している前に入れてください。
- CLI ツール:パブリック GitHub リポジトリにプッシュして、インストールと実行コマンドを正確に示す 2 段落の README を付ける
- Web アプリ:Render、Fly.io、または $5 DigitalOcean droplet にデプロイします。ユーザーが 1 人のプロジェクト用に 3 日間 Kubernetes オプションを比較するのに費やさないでください
- スクリプト:cron ジョブまたは GitHub Action をセットアップして、触らなくても実行できるようにします
デプロイメント摩擦は、技術的な課題より多くのサイドプロジェクトを殺します。Render のようなプラットフォームに git push するのが今のところ多すぎる場合は、ローカルで実行されている 90 秒の Loom ビデオを記録して送信してください。重要なのは外部の証拠であり、インフラストラクチャの成熟度ではありません。
何が壊れたかを書き下す
リリース後、15 分をかけて、うまくいかなかった 3 つのことと、どのように修正したかを書いてください。他の誰かのためではなく、自分自身のためにです。これが実際の学習です。チュートリアルはあなたに構文を教えました。壊れた pip install、CORS エラー、真夜中のオフバイワン日付バグ、これらはソフトウェアが実際にどのように動作するかを教えます。
これらのメモを 1 つの実行中のファイルに保管してください。5 つか 6 つの小さなプロジェクトの後、同じバグのカテゴリが表示され始めます。これがあなたの本当のカリキュラムです:チュートリアルがカバーしないギャップです。
その後、次のものを選んでください、少し大きく
CLI スクリプトから分散システムにジャンプしないでください。一度に複雑さを 1 つの側面を追加します:次のプロジェクトは CSV の代わりにデータベース、または基本的なテストスイート、または 2 番目のユーザーを取得します。小さな複合ステップは 3 週目で停止する 1 つの野心的な書き換えに勝ちます。
この後、構造化されたステップが必要な場合は、Korra Studio の Python と DevOps セグメントが、最初のリリースプロジェクト後に人々がつまずく傾向があるデプロイメントとツール作成のギャップをカバーしています。
この記事は AI の支援を受けて執筆し、Korra Studio の Michal Pilch(CISSP)が確認のうえ公開しました。
これは Korra Studio ナレッジベースの 1 つのノートです。プラットフォームはすべてのトピックと 1 対 1 メンタリングをペアで提供します。
無料で始めるarrow_forward