تقریباً ۳ هفته‌اس دارم این پروژه رو میزنم با
Rust, Tauri v2

و هرچی دوستان بیشتری تست می‌کنند ایده‌های جالبتری بهش اضافه می‌شه.
فعلاً فقط نسخه لینوکس رو داریم و روی ورژن
v0.2.0
هستیم (شاید بعداً ویندوز و مک هم اضافه شد)


اگر دوست داشتید تست کنید توی کانال
https://t.me/per3onnel

فایل‌های باینتری برای دبیان، ردهت و آرچ وجود داره

پینوشت:
بعد از انتشار v1.0.0 بصورت open source منتشر خواهد شد

#Quick@pyHints


حالا که همه دارند از قابلیت Lazy import توی پایتون ۳.۱۵ میگن گفتم یادآوری کنم:

اگر پروژه تست نداشته باشه و توی توسعه‌ی یک فیچر یا بخش اون ماژول که Lazy import داره صدا زده نشه و به import نیازی نباشه، ارورهای اون بخش رو نمی‌بینیدا

اینم یک دلیل خوب دیگه که باید تست بنویسید.

چند ماه پیش به واسطه یکی از دوستان و به خواست ایشون به یک نفر یک مقدار پیشنهاد و ... برای مسیر شغلی دادم (بکند) البته بیشتر هدف راهنمایی کردن بود.

ماه پیش با چندتا از هم دانشگاهی‌هاش درخواست دادند که بهشون آموزش بدم، که خب کار من نیست.
ولی نقش منتور رو قبول کردم، ۷ نفر شدند تا هزینه‌ها کمتر بشه.
شبی ۲ ساعت برای جواب به سوالات (تا آخر شب سوالاتشون رو جمع می‌کنند و آخر شب تو گروه می‌پرسند)
آخر هفته‌ها هم تا ۴ ساعت جلسه آنلاین.

سخت‌ترین بخش اینکار هماهنگ کردن ساعت و روزی بود که برای همه شدنی باشه، هیچکدوم از بچه‌ها ایران نیستند.
۲ تا از بچه‌ها تازه شروع کردند سرکار رفتن و جونیور هستند.
۳ نفر دانشجو هستند و مقدمات پایتون رو می‌دوند.
یک نفر تخصصش هوش مصنوعی هست و می‌خواد بکند یاد بگیره.
یک نفر هم توی یکی از شرکت‌های خدمات ابری کار می‌کنه و می‌خواد وارد تیم سرویس و بکند بشه.

خلاصه تیم جالبی شد، شرط اولیه برای همگی بلد بودن پایتون تو سطح متوسط بود.
با هر نفر ۱۵ دقیقه جلسه داشتم، اگر قبول نمی‌شد نمی‌تونست وارد گروه بشه، لیست ۱۰ نفره بود که ۳ نفر رد شدند.

۲-۳ روز پیش شروع کردم بر اساس ایده پروژه‌هایی که خودشون دادند یک roadmap نوشتن.

برای هر کدوم از بچه‌ها roadmap جداشد (آخر هفته‌ها قراره همین پروژه‌ها رو بخونیم) دلیلشم این بود که هرکدوم ایده خودشون رو داشتند، مثلاً بچه‌هایی که شاغل بودند می‌خواستند چیزی رو کد بزنند که به کارهاشون نزدیک هست.
باقی بچه‌ها، ایده‌های ساده یا استارتاپی داشتند.

حالا که تموم شد و تأیید؛؛؛ گفتم شاید بد نباشه اینجا هم به اشتراک بذارم.

توضیحات بالا برای این بود که اصل داستان رو بدونید و توجه کنید که دلیل roadmap ایی که توی پست بعدی خواهید دید چی هست.

توجه کنید که roadmap پست بعدی درحد کلمه هست، من توقع دارم شما در سطح متوسط پایتون رو بلد باشید و یک دوره ۱ ساعته یک جایی از زندگیتون نشسته باشید و یک فریمورک وب رو به آموزشش گوش داده باشید.


#از_کانال_قبلی

#Backend_RoadMap_2025

قبل از اینکه بخواید این roadmap رو دنبال کنید باید پست قبلی رو بخونید.
یک نکته‌ای که اضافه کنم؛ توی جلسات و ... که بحث شد من اصلا قرار نیست هیچ چیزی رو آموزش بدم (اشتباهات رو کمک می‌کنم حل بشه و ...) اما اینکه آموزش بدم FastAPI چیست و جطوری CRUD بنویسیم و ازین موارد با اوضاع الانم اصلا نمی‌خونه پس دلیل ساده بودنش همین پست قبلی هست.

چیزایی که توقع دارم یک Senior توی جنبه‌ی فنی بکند بلد باشه (اعداد هیچ ربطی به ترتیب یادگیری نداره؛ فقط برای این هست که تهش بدونم چندتا مورد رو گفتم) از دوستان Senior هم می‌خوام اگر نکته یا موردی جا افتاده بهم یادآوری کنند.
بازم توجه کنید Senior شدن کلی جنبه‌های مختلف داره ولی برای بخش فنی مربوط به بکند این لیست کافی و قوی هست؛ برای بحث‌های دیگر هم از منابع خودش می‌تونید دنبال کنید.

فریمورک مورد نظرتون رو کمی بشناسید (من روی FastAPI پیش میرم ولی خیلی فرقی نیست)

1. Middleware: Starlette interface for how to write middleware.
Must know: auth, request ID, timing, gzip, validators, rate-limit, logging.
Important to know the order of execution.

2. CORS (and headers in general).

3. Authentication / Authorization: What is JWT + RS256.
Nice to know: Auth0, Cognito.

4. SQL and SQLAlchemy 2.0 (async style).

5. Tests:
* Unit tests for business logic.
* Integration tests for database, Redis, etc. interactions.
* Contract tests (very important) for endpoints and services you use.

6. Benchmarking: k6, load testing, CI smoke tests for performance-sensitive endpoints; wrk, hyperfine (or alternatives).

7. Docker / Docker Compose: multi-stage builds.

8. Profiling: Scalene or Perf — flamegraph interpretation.

9. Caching (Redis): cache invalidation; GET/SET strategies (Cache-Aside vs Write-Through).

10. Background tasks:
FastAPI background tasks & Dramatiq (or other alternatives).
Don't bring Celery or its equivalent into projects — it's heavy and overkill in most cases.
Use/understand: idempotency, retries, dead-lettering.

11. Observability: Logging, tracing, metrics.
Logs must be structured (JSON is a good option).
Distributed tracing is a must-have.
Metrics (Prometheus) are important — at minimum: response_time_ms, active_connections, etc.

12. Configuration management: Pydantic Settings; no hard-coded settings or configs.

13. Migrations: Alembic — each migration should have both UP and DOWN so it is safe to revert.

14. API documentation: FastAPI provides it automatically, but don't forget to use the Pydantic model example field.
BTW: Pydantic v2 is the only accepted version.

15. Error handling + correct HTTP codes.

16. Graceful shutdown:
App must stop accepting new HTTP connections,
finish processing current requests,
drain the database connection pool,
then exit.

17. Idempotency and retries:
For network/database failures — learn exponential backoff, circuit breakers, bulkheads.

18. Health checks and readiness probes: The app must provide them (Docker health check alone is not accepted).

19. Connection pooling tuning: Postgres, Redis, etc.
You must be able to explain tuning decisions based on your benchmarks/profiling results.

20. Security basics: Input sanitization/validation, rate limiting, secrets management, secure defaults (CSP, HSTS), threat modeling for endpoints.

21. Scalability patterns: Focus on connection pooling and indexing first.
Too many or unnecessary indexes = Fail.
Nice to learn: horizontal scaling, load balancing, sharding, replication.

22. Feature flagging (dynamic configuration): All projects should have it — very important.

23. API versioning strategy: Header versioning / URL versioning.

24. Architecture Decision Records
From day 1 you must have this document in the project with at least 3 entries per decision:
What you decided.
Why you did that.
What the consequences are.
--————————————-
Future / next steps

1. Design system architecture.
2. Integrate message queues (when and why to use them) — Kafka, RabbitMQ.
3. Event-driven patterns.
4. Optimize for latency.
5. GraphQL / gRPC — when and why to use them.


پینوشت: اگر جایی کپی کردید؛ لطفا پیام قبلی و بعدی رو هم بذارید 🌱
توضیحات مهم هست.

#از_کانال_قبلی

چیزای دیگه مثل کانفیگ pre-commit, black, isort, ... یا بطورکلی ruff
مواردی مثل داشتن Makefile یا جایگزین‌های مختلف اون
اسکریپت برای اتومات کردن کارهای دستی که باید انجام بشه (قبل یا بعد از هر دپلوی)
و از این دست موارد جزو چیزهایی هست که همه افراد شرکت کننده باهاش آشنایی داشتند یا قبول کردند توی پست‌های کانال یا جاهای دیگه بخونند.
رعایت استاندارد و خوانایی و ...
موارد دیفالت بود که نیازی به توضیح دادن نداشت و همه باید دنبال کنند.

توی یک سری موارد زدم Fail , not acceptable چون روز اول شرط کردیم اگر کسی بیش از ۴ هفته کدهاش تایید نشه حذف می‌شه (برای اینکه وقت باقی افراد رو با سوالات مسخره که از نخوندن و تمرین نکردن عمدی میاد نگیره) همه افراد هم هزینه‌ها رو پرداخت کردند؛ البته من از شخصی که تیم رو جمع کرد هزینه رو میگیرم و ازش خواستم بعد از تکمیل مباحث هر بخش پرداخت رو انجام بده.

کلا ۶ تا بخش میشه که قرار هست توی ۶ ماه تکمیل بشه (شاید زودتر) ولی با توجه به امتحانات و تعطیلی و ... تا ۸ ماه قابل افزایش هست (من پیشنهادم ۴ ماه بود خودشون توافق کردند بیشتر بشه)

پینوشت: دانش بیزینس رو من نمی‌تونم چیزی راجبش بگم قطعا چون ۷ نفر با ایده‌های مختلف و از بخش‌های مختلف وارد شدند.

#از_کانال_قبلی

#موقت

بهم گفتند که اون پیام پاک شده برای همین مجدد فرستادم.

دوستان من چون owner کانال قبلی بودم برای من همچنان پیام‌ها نمایش داده میشه (البته که کانال بن شده سرچ نداره)
اگر پیامی اینجا هست که نمی‌تونید متنش رو ببینید و نیاز داشتید -> برام فروارد کنید تا مجدد بفرستم یا بزارم براتون