این هفته یک چیز کوچک منتشر کنید

بیشتر افرادی که در حلقه‌های آموزشی گیر افتاده‌اند، مشکل مهارت ندارند. آن‌ها مشکل منتشر کردن دارند. می‌توانید چهل ساعت محتوای Python تماشا کنید و همچنان هنگامی که برای ساخت چیزی برای خودتان نشسته‌اید، فریز شوید، زیرا آموزش‌ها هر تصمیمی را از شما برمی‌دارند. این راهنما یک تابع اجباری است: چیزی کوچک انتخاب کنید، آن را تمام کنید، آن را جلوی کسی قرار دهید، این هفته.

یک پروژه انتخاب کنید که می‌توانید در یک آخر هفته تمام کنید

حالت شکست اینجا محدوده است. مردم تصمیم می‌گیرند که اولین پروژه آن‌ها باید یک اپ SaaS با احراز هویت، صورت‌حساب و داشبورد باشد. این یک پروژه شش‌ماهه است که به‌عنوان یک آخر هفته درآمده است.

بجای آن چیزی انتخاب کنید که یک تابع واضح دارد:

• یک ابزار CLI که فایل‌ها را در یک پوشه بر اساس تاریخ EXIF تغییر نام می‌دهد
• یک اسکریپت که یک API عمومی را جستجو می‌کند و برای شما یک خلاصه روزانه ایمیل می‌کند
• یک اپ Flask با یک فرم و یک صفحه خروجی
• یک افزونه مرورگر که یک کلمه کلیدی را در هر صفحه‌ای که از آن بازدید می‌کنید برجسته می‌کند

محدوده را در یک جمله قبل از نوشتن هر کد بنویسید. اگر جمله نیاز به "و" بیش از یک‌بار دارد، آن را حذف کنید. "یک ابزار که هزینه‌های من را ردیابی می‌کند و همچنین آن‌ها را دسته‌بندی می‌کند و همچنین آن‌ها را نمودار می‌کند" سه پروژه است. ابتدا ردیاب را منتشر کنید.

یک deadline واقعی و یک audience واقعی تعیین کنید

یک deadline بدون نتیجه، یک deadline نیست. به دوستی بگویید، در سرور Discord بنویسید، یا خود را متعهد کنید که آن را برای یک همکار جمعه نمایش دهید. Audience مهم‌تر از deadline است — دانستن اینکه کسی واقعاً به چیز نگاه خواهد کرد، روش ساخت شما را تغییر می‌دهد. شما از معماری طلا-کاری کردن دست می‌کشید و شروع به اطمینان می‌دهید که مسیر موفقیت واقعاً کار می‌کند.

خود را یک عدد بدهید، نه یک احساس. "هنگامی که وقت دارم روی آن کار خواهم کرد" هیچ‌چیز تولید نمی‌کند. "دو ساعت امشب، دو ساعت فردا، منتشر کردن صبح شنبه" یک پروژه تولید می‌کند.

ابتدا نسخه زشت را بسازید

بحث‌های ساختار پوشه را رها کنید، انتخاب یک چارچوب CSS را رها کنید، تصمیم بین Postgres و SQLite برای ابزاری که چهل ردیف ذخیره خواهد کرد را رها کنید. یک فایل بنویسید. بجای logger از عبارات print() استفاده کنید. اگر تنها چیزی است که نیاز دارید، بجای یک پایگاه داده از یک لیست Python استفاده کنید.

# expenses.py - نسخه زشت، و این خوب است
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 درصد راه برای چیزی که می‌توانید واقعاً فردا استفاده کنید، می‌برد. می‌توانید یک چیز زشت کار کردن را refactor کنید. نمی‌توانید یک چیز قشنگ که وجود ندارد را refactor کنید.

آن را جایی استقرار دهید، حتی بدطور

یک پروژه در لپ‌تاپ شما به‌عنوان منتشر شده محسوب نمی‌شود. آن را جلوی اینترنت یا جلوی شخصی قرار دهید که خود آن را اجرا می‌کند.

• ابزار CLI: آن را به یک repo GitHub عمومی push کنید با یک README دو پاراگرافی که دستورات دقیق install و run را نشان دهد
• اپ وب: برای Render، Fly.io، یا یک droplet DigitalOcean 5 دلاری استقرار دهید — سه روز را برای مقایسه گزینه‌های Kubernetes برای یک پروژه با یک کاربر تلف نکنید
• اسکریپت: یک cron job یا GitHub Action را تنظیم کنید تا بدون دستکاری شما اجرا شود

اصطکاک استقرار بسیاری از پروژه‌های side را بیش از هر چالش فنی می‌کشد. اگر git push به یک platform مانند Render در حال حاضر بیش از حد است، فقط یک ویدیو 90 ثانیه‌ای Loom از آن در حال اجرا locally ضبط کنید و آن را ارسال کنید. نکته اثبات خارجی است که کار می‌کند، نه بلوغ زیرساخت.

آنچه شکست خورد را بنویسید

بعد از منتشر کردن، 15 دقیقه را صرف نوشتن سه چیزی کنید که اشتباه رفت و چگونه آن را درست کردید. برای کسی دیگری نه — برای خودتان. این یادگیری واقعی است. آموزش شما را syntax آموخت. pip install شکسته، خطای CORS، باگ تاریخ off-by-one در نیمه‌شب — آن‌ها شما را آموزش می‌دهند که نرم‌افزار واقعاً چگونه رفتار می‌کند.

این یادداشت‌ها را در یک فایل متوالی نگه دارید. بعد از پنج یا شش پروژه کوچک، متوجه خواهید شد که دسته‌های باگ یکسانی دوباره نمایان می‌شود، و این curriculum واقعی شماست: شکاف‌هایی که آموزش‌ها هرگز پوشش نمی‌دهند.

سپس چیز بعدی را انتخاب کنید، کمی بزرگ‌تر

از یک اسکریپت CLI به یک سیستم توزیع‌شده پرش نزنید. یک بعد پیچیدگی را در یک زمان اضافه کنید: پروژه بعدی جای CSV یک پایگاه داده دارد، یا یک test suite ابتدایی، یا یک کاربر دوم. مراحل کوچک و مرکب مراحل بزرگ‌تر از یک بازنویسی بدون ایده‌آل که در هفته سوم متوقف شود را شکست می‌دهند.

اگر بعد از این مراحل structured بعدی می‌خواهید، بخش‌های Python و DevOps Korra Studio دقیقاً شکاف‌های استقرار و tooling را پوشش می‌دهند که تمایل دارند افراد را بعد از اولین پروژه منتشر شده خود گیج کنند.