Python Hints
Python tips and tricks The Good, Bad and the Ugly توی این کانال فقط قرار هست در مورد core python صحبت کنیم. این کانال یک بلاگ شخصی هست و پیرامون نظرات و چیزهایی که توی بیش از ۱۰ سال کد زدن یاد گرفتم (فقط برای کمک به دوستان تازهکار) Admin: @Abbasi_ai
Ko'proq ko'rsatish📈 Telegram kanali Python Hints analitikasi
Python Hints (@pyhints) Forsiy til segmentidagi kanali faol ishtirokchi. Hozirda hamjamiyat 10 265 obunachidan iborat bo'lib, Texnologiyalar & Aralashmalar toifasida 11 941-o'rinni va Eron mintaqasida 31 974-o'rinni egallagan.
📊 Auditoriya ko‘rsatkichlari va dinamika
невідомо sanasidan buyon loyiha tez o‘sib, 10 265 obunachiga ega bo‘ldi.
09 Noyabr, 2026 dagi oxirgi ma’lumotlarga ko‘ra kanal barqaror faollikka ega. Oxirgi 30 kunda obunachilar soni 97 ga, so‘nggi 24 soatda esa 1 ga o‘zgardi va umumiy qamrov yuqori darajada qolmoqda.
- Tasdiqlash holati: Tasdiqlanmagan
- Jalb etish (ER): Auditoriya o‘rtacha 28.90% darajada jalb etiladi. Nashrdan keyingi dastlabki 24 soatda kontent odatda umumiy obunachilar sonining 10.66% ini tashkil etuvchi reaksiyalarni to‘playdi.
- Post qamrovi: Har bir post o‘rtacha 2 966 marta ko‘riladi; birinchi sutkada odatda 1 094 ta ko‘rish yig‘iladi.
- Reaksiyalar va o‘zaro ta’sir: Auditoriya faol: har bir postga o‘rtacha 21 ta reaksiya keladi.
- Tematik yo‘nalishlar: Kontent ᴘʀᴏxʏ, کانفیگ, مورد, shift, ابزار kabi asosiy mavzularga jamlangan.
📝 Tavsif va kontent siyosati
Muallif resursni shaxsiy fikrni ifoda etish maydoni sifatida ta’riflaydi:
“Python tips and tricks
The Good, Bad and the Ugly
توی این کانال فقط قرار هست در مورد core python صحبت کنیم.
این کانال یک بلاگ شخصی هست و پیرامون نظرات و چیزهایی که توی بیش از ۱۰ سال کد زدن یاد گرفتم (فقط برای کمک به دوستان تازهکار)
Admin: @Abbasi...”
Yuqori yangilanish chastotasi (oxirgi ma’lumot 10 Noyabr, 2026 da olingan) sababli kanal doimo dolzarb va katta qamrovli bo‘lib qoladi. Analitika auditoriya kontent bilan faol hamkorlik qilishini, uni Texnologiyalar & Aralashmalar toifasidagi muhim ta’sir nuqtasiga aylantirishini ko‘rsatadi.
Ma'lumotlar yuklanmoqda
| Sana | Obunachilarni jalb qilish | Esdaliklar | Kanallar | |
| 10 Noyabr | +2 | |||
| 09 Noyabr | +2 | |||
| 08 Noyabr | +1 | |||
| 07 Noyabr | +5 | |||
| 06 Noyabr | +4 | |||
| 05 Noyabr | +11 | |||
| 04 Noyabr | +4 | |||
| 03 Noyabr | +1 | |||
| 02 Noyabr | +6 | |||
| 01 Noyabr | +3 |
| 2 | در ادامه سری پرامپتهایی که شخصا استفاده میکنم یک پرامپت برای یادگیری کتابخونههای جدید هم دارم که خیلی وقته ازش استفاده میکنم گفتم اینجام بگم بعد از این همه مدت.
Imagine a person who knows all the concepts of <FIELD NAME> and want to learn <LIBRARY NAME>
<A SOURCE CODE FROM ANY GITHUB PROJECT>
how would you explain him this source code so that he can start coding using this library after your tutorial ?
توی این پرامپت جای چندتا چیز رو عوض کنید
<FIELD NAME>
<LIBRARY NAME>
<A SOURCE CODE FROM ANY GITHUB PROJECT>
برای مثال به ترتیب میشه:
Backend development
FastAPI
نمونه سورسکد هم از پروژههای مختلف توی گیتهاب میتونید پیدا کنید که open source هستند.
البته شخصا لایبراری خیلی بزرگ رو یکجا بهش نمیدم ولی خب احتمال اینکه شما هم مثل من توی مرورگر ازش فقط استفاده کنید کم هست.
روی اکانتهای پولی میتونید بهش بگید اون رو بصورت آموزش با motion graphic هم براتون در بیاره
اگر سورس کد خوبی بهش بدید؛ از ۱۰۰۰ تا دوره خریدن بهتر جواب میده
بخصوص اگر بعدش شروع کنید به کد زدن و همزمان برای نیازهاتون داکیومنت هم بخونید.
#learn_with_ai | 2 292 |
| 3 | برای نیروی جدید تیم review گذاشتم که بجای assert از raise استفاده کنه براش سوال شد چرا ؟
توی پروداکشن وقتی از فلگ اپتیمایزیشن
-O
استفاده میکنیم assert ها غیر فعال میشه و اجرا نخواهند شد؛ چون توی این پروژه هم داریم همینکار رو میکنیم شما نمیتونی از assert استفاده کنی؛ مگر برای دیباگ و ...
گفتم اینجا هم بگم شاید بدرد دوستان خورد؛ غیر از این هم اگر استفاده کردید شاید بهتر باشه یکجایی بهش اشاره کنید که تیم DevOps بعدها از فلگ اپتیمایز برای دپلوی استفاده نکنه یا حتی بهتر توی کدها اولویت رو روی raise بذارید نه assert | 2 824 |
| 4 | Upgrade certifi, pip, and uv in response to CA certificate incident
pypi altert | 4 066 |
| 5 | #موقت
بهم گفتند که اون پیام پاک شده برای همین مجدد فرستادم.
دوستان من چون owner کانال قبلی بودم برای من همچنان پیامها نمایش داده میشه (البته که کانال بن شده سرچ نداره)
اگر پیامی اینجا هست که نمیتونید متنش رو ببینید و نیاز داشتید -> برام فروارد کنید تا مجدد بفرستم یا بزارم براتون | 5 530 |
| 6 | چیزای دیگه مثل کانفیگ pre-commit, black, isort, ... یا بطورکلی ruff
مواردی مثل داشتن Makefile یا جایگزینهای مختلف اون
اسکریپت برای اتومات کردن کارهای دستی که باید انجام بشه (قبل یا بعد از هر دپلوی)
و از این دست موارد جزو چیزهایی هست که همه افراد شرکت کننده باهاش آشنایی داشتند یا قبول کردند توی پستهای کانال یا جاهای دیگه بخونند.
رعایت استاندارد و خوانایی و ...
موارد دیفالت بود که نیازی به توضیح دادن نداشت و همه باید دنبال کنند.
توی یک سری موارد زدم Fail , not acceptable چون روز اول شرط کردیم اگر کسی بیش از ۴ هفته کدهاش تایید نشه حذف میشه (برای اینکه وقت باقی افراد رو با سوالات مسخره که از نخوندن و تمرین نکردن عمدی میاد نگیره) همه افراد هم هزینهها رو پرداخت کردند؛ البته من از شخصی که تیم رو جمع کرد هزینه رو میگیرم و ازش خواستم بعد از تکمیل مباحث هر بخش پرداخت رو انجام بده.
کلا ۶ تا بخش میشه که قرار هست توی ۶ ماه تکمیل بشه (شاید زودتر) ولی با توجه به امتحانات و تعطیلی و ... تا ۸ ماه قابل افزایش هست (من پیشنهادم ۴ ماه بود خودشون توافق کردند بیشتر بشه)
پینوشت: دانش بیزینس رو من نمیتونم چیزی راجبش بگم قطعا چون ۷ نفر با ایدههای مختلف و از بخشهای مختلف وارد شدند.
#از_کانال_قبلی | 4 891 |
| 7 | #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.
پینوشت: اگر جایی کپی کردید؛ لطفا پیام قبلی و بعدی رو هم بذارید 🌱
توضیحات مهم هست.
#از_کانال_قبلی | 3 436 |
| 8 | چند ماه پیش به واسطه یکی از دوستان و به خواست ایشون به یک نفر یک مقدار پیشنهاد و ... برای مسیر شغلی دادم (بکند) البته بیشتر هدف راهنمایی کردن بود.
ماه پیش با چندتا از هم دانشگاهیهاش درخواست دادند که بهشون آموزش بدم، که خب کار من نیست.
ولی نقش منتور رو قبول کردم، ۷ نفر شدند تا هزینهها کمتر بشه.
شبی ۲ ساعت برای جواب به سوالات (تا آخر شب سوالاتشون رو جمع میکنند و آخر شب تو گروه میپرسند)
آخر هفتهها هم تا ۴ ساعت جلسه آنلاین.
سختترین بخش اینکار هماهنگ کردن ساعت و روزی بود که برای همه شدنی باشه، هیچکدوم از بچهها ایران نیستند.
۲ تا از بچهها تازه شروع کردند سرکار رفتن و جونیور هستند.
۳ نفر دانشجو هستند و مقدمات پایتون رو میدوند.
یک نفر تخصصش هوش مصنوعی هست و میخواد بکند یاد بگیره.
یک نفر هم توی یکی از شرکتهای خدمات ابری کار میکنه و میخواد وارد تیم سرویس و بکند بشه.
خلاصه تیم جالبی شد، شرط اولیه برای همگی بلد بودن پایتون تو سطح متوسط بود.
با هر نفر ۱۵ دقیقه جلسه داشتم، اگر قبول نمیشد نمیتونست وارد گروه بشه، لیست ۱۰ نفره بود که ۳ نفر رد شدند.
۲-۳ روز پیش شروع کردم بر اساس ایده پروژههایی که خودشون دادند یک roadmap نوشتن.
برای هر کدوم از بچهها roadmap جداشد (آخر هفتهها قراره همین پروژهها رو بخونیم) دلیلشم این بود که هرکدوم ایده خودشون رو داشتند، مثلاً بچههایی که شاغل بودند میخواستند چیزی رو کد بزنند که به کارهاشون نزدیک هست.
باقی بچهها، ایدههای ساده یا استارتاپی داشتند.
حالا که تموم شد و تأیید؛؛؛ گفتم شاید بد نباشه اینجا هم به اشتراک بذارم.
توضیحات بالا برای این بود که اصل داستان رو بدونید و توجه کنید که دلیل roadmap ایی که توی پست بعدی خواهید دید چی هست.
توجه کنید که roadmap پست بعدی درحد کلمه هست، من توقع دارم شما در سطح متوسط پایتون رو بلد باشید و یک دوره ۱ ساعته یک جایی از زندگیتون نشسته باشید و یک فریمورک وب رو به آموزشش گوش داده باشید.
#از_کانال_قبلی | 2 516 |
| 9 | #موقت
بهم گفتند که اون پیام پاک شده برای همین مجدد فرستادم.
دوستان من چون owner کانال قبلی بودم برای من همچنان پیامها نمایش داده میشه (البته که کانال بن شده سرچ نداره)
اگر پیامی اینجا هست که نمیتونید متنش رو ببینید و نیاز داشتید -> برام فروارد کنید تا مجدد بفرستم یا بزارم براتون | 277 |
| 10 | #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.
پینوشت: اگر جایی کپی کردید؛ لطفا پیام قبلی و بعدی رو هم بذارید 🌱
توضیحات مهم هست. | 262 |
| 11 | #Quick@pyHints
حالا که همه دارند از قابلیت Lazy import توی پایتون ۳.۱۵ میگن گفتم یادآوری کنم:
اگر پروژه تست نداشته باشه و توی توسعهی یک فیچر یا بخش اون ماژول که Lazy import داره صدا زده نشه و به import نیازی نباشه، ارورهای اون بخش رو نمیبینیدا
اینم یک دلیل خوب دیگه که باید تست بنویسید. | 4 291 |
| 12 | تقریباً ۳ هفتهاس دارم این پروژه رو میزنم با
Rust, Tauri v2
و هرچی دوستان بیشتری تست میکنند ایدههای جالبتری بهش اضافه میشه.
فعلاً فقط نسخه لینوکس رو داریم و روی ورژن
v0.2.0
هستیم (شاید بعداً ویندوز و مک هم اضافه شد)
اگر دوست داشتید تست کنید توی کانال
https://t.me/per3onnel
فایلهای باینتری برای دبیان، ردهت و آرچ وجود داره
پینوشت:
بعد از انتشار v1.0.0 بصورت open source منتشر خواهد شد | 4 981 |
| 13 | تم دیفالت Kanagawa هست و ۷ تم معروف دیگر ترمینال هم بصورت پیشفرض وجود داره (تمهایی که اضافه میکنید بین ورژنها آپدیت نمیمونه؛ اگر فکر میکنید لازم هست که این مورد رو هم اضافه کنم که توی دیتابیس ذخیره بشه)
Kanagawa (default)
Argonaut
Tokyo Night
Catppuccin Mocha
Nord
Gruvbox Dark
One Dark
Night Owl | 4 221 |
| 14 | git commit --allow-empty -m "from: develop"
لطفا دستور بالا رو یاد بگیرید البته بخش commit message رو خودتون باید تغییر بدید و بعد از یادگیری خواهشا استفاده کنید.
برای یک کار موقت وارد شدم؛ فکر کنم بالای ۷۰ تا برنچ دارند (مدیر فنی خدافظی کرده و سنیورهارو هم اخراج شدند.)
حالا ۷۰ تا برنچ هست که هرکدوم یک سری فیچر رو اضافه کردند؛ هیچکدوم مرج نشده و پروژه از روی یکی از برنچها دپلوی شده باقی برنچها هم هرکدوم یکی از فیچرهای پروژه رو داره که لازم بوده و ...
و البته که
git log —graph
و ... وجود داره ولی انقدر بهم ریخته و کثیف شده که خوندن اونم دردسر داره.
اضافه کردن یک کامیت خالی که فقط بگه برنچ parent چیزی که توسعه داده میشه کی هست باعث میشه بعدا خودتون هم راحت باشید و خواهشا وقتی چیزی رو merge میکنید حتما برنچ رو پاک کنید. اگر فکر میکنید حذف نکردن برنچ بعدا کمک شما خواهد کرد شما مشکل مهارتی git دارید و معلوم هست git رو درست یاد نگرفتید.
با سنیورها تماس گرفته شده هرکسی چندتا برنچ رو یادش هست و کمک کرد ولی خب خیلی برنچها نامشخص هست. | 3 827 |
| 15 | میدونستید کل ارائه رو میتونید به comic book تبدیل کنید ؟
هر مدلی که Image generation داشته باشه (مثال بالا Gemini Notebook هست)
برای کسایی که حافظه تصویری قویتری دارند این روش خیلی جواب هست.
پینوشت:
سورس دیتای تصویر بخشی از ارائه خودم هست؛ قراره ۱۲-۱۶ ساعت آموزش Axum بدم.
بطوریکه از روز بعدش بکند پروژه جدید رو روی Axum شروع به کد زدن کنند و از اونجایی که از درست کردن powerpoint نفرت دارم؛ به ذهنم رسید این کار رو بکنم (چون ۹۰٪ کد هست) برای مواقعی که کد نیست و باید توضیح بدم این بهترین گزینه هست بنظرم. | 3 689 |
| 16 | ملت skill issue های خودشون رو میندازند گردن پایتون. | 5 016 |
| 17 | At its peak, Python helped us serve more than 20 million requests every second.
تیم مهندسی openai یک مقاله داده در مورد یک لایبراری برای دسترسی سادهتر به دیتابیس که با پایتون روز اول نوشته شده بوده و بعد به سرویس پایتون تبدیل شده و نشون داده با طراحی درست سیستم تا ۲۰ میلیون درخواست رو داشتند باهاش هندل میکردند.
البته توی این مقاله راجب تصمیم برای سوییچ کردن به Rust صحبت شده ولی کل مقاله رو اگر بخونید از ابتدا درمورد مزایای استفاده از پایتون برای اینکار هست؛ پیشنهاد میکننم حتما این مقاله رو بخونید (پارت دوم هم داره که scale اش رو میگه)
علاوه بر اون برای دوستان علاقمند پیشنهاد میکنم حتما مقاله مربوط به Postgres رو هم بخونید بخصوص اگر توی تیمی هستید که از روز اول Shard کردن رو دوس داره.
How we adapted our application storage platform, Habitat, in Python to manage unprecedented growth. (Part 1)
Scaling PostgreSQL to power 800 million ChatGPT users | 5 475 |
| 18 | @pyhints
انقدر محبوب و معروف شده که پیشنهاد اسپانسر و تبلیغات دلاری براش داره میاد؛ توی تمام این سالها هیچکدوم از کانالها تبلیغات نداشته و ترجیح میدم این روند رو ادامه بدم.
اما باید از تمام دوستانی که این مدت همراه کانال بودند و مطالب رو به اشتراک گذاشتند هم تشکر کنم.
بابت همراهی شما با تمام کانالها و تمام این سالها ممنونم
@pyhints
@pytens
@pyrust
@per3onnel | 5 413 |
| 19 | داشتم دنبال یک ویدئو میگشتم که ببینم کسی ماژولهای مهم رو برای پایتون توضیح داده ؟
یک بخشی از داکیومنت رو خوندم و فهمیدم ماژول چیزی هست که دنبالشم و توی این سرچ متوجه شدم ۳ سال قبل با این ابزار آشنا شدم؛ یا اون موقع بدردم نمیخورده یا پروژههام همه رو اسکریپت بوده و کار میکرده یا ایراداتی داشته که نتونستم استفاده کنم.
خواستم این نکته رو هم اضافه کنم که :
هرچیزی به زمانش و به وقت نیاز بهش خوبه؛ چیزی که امروز خیلی راجبش هیجان دادم و خوشم اومد از پیدا کردنش
۳ سال قبل (کل ویدئو رو دیده بودم) هیجان زدم نکرده شاید به این فکر کردم که خودم با اسکریپت دارم همینکارو میکنم دیگه باقیشم که .env و پایتون انجام میده
امروز نیاز و نگاهم عوض شده
اگر جونیور هستید و توی تیم میخواید ابزار جدیدی رو پیشنهاد بدید یادتون باشه باید نشون بدید :
۱- این ابزار جایگزین روش قبلی هست
۲- جایگزین کردن ابزار قدیم چقدر هزینه داره (یادگیری نیروهای دیگه هم در نظر بگیرید)
۳- مزیتهاش چیه
که بازم بر میگرده به یکی از مهمترین چیزایی که قبلا گفتم حتما یاد بگیرید یعنی نوشتن ADR اونم صادقانه هم مزایا و هم معایب | 5 809 |
| 20 | این دقیقا یکی از اون جاهایی هست که گفتم نیروی جونیور توی تیم لازم هست.
مسئله این هست که من اسکریپتهام و راهاندازی کانتینر dev برای ابزارها و کانفیگشون با اسکریپت و ... رو شاید ۱-۲ ماه بعد از یادگیری داکر (اوایل معروف شدن) شروع کردم همین امروز هم اگر تنبلی باعثش نبود عمرا همچین چیزی رو سرچ نمیکردم.
حتی اگر احمق بودن بیش از حد LLM ها نبود هم اینکار رو نمیکردم؛فیچرهایی که خواستم تست کنم جدید بود و البته چون نمیدونستم رفتار درست ابزارها روی فیچرهای جدید چی هست و چطوری عمل میکنه اعتمادی به LLM برای نوشتن این اسکریپت نداشتم دلیلش هم واضح هست :
از کجا بفهمم خطا توی کدم هست؛ یا توی اسکریپت LLM یا حتی اون فیچر رو اشتباه درک کردم یا اشتباه استفاده کردم و ...
این باعث شد سرچ کنم و testcontainers رو پیدا کنم؛ من همیشه محیط تست و توسعهام یکی هست همه چیزش.
روی پروداکشن هم سرور dev, stage و prod همیشه یکسان کانفیگ میشه حتی تا سطح دسترسی و جزئیاتی مثل firewall , ...
فقط تفاوت این میشه که مثلا prod با ۱۰ تا سرور میاد بالا dev با ۱ سرور و stage با ۳ تا سرور اگر جنبه distribute بودن چیزی باشه که برامون مهم هست تست شدنش.
خلاصه اینا معمولا دانشی هست که یک جونیور خوب به تیم اضافه میکنه؛ توی جلسات هفتگی یا حتی ماهانه راهکارهای جدید و به روز شده رو جونیورها معمولا به تیم اضافه میکردند وگرنه من و مثل من که ۱۰ سال هست یک راهکار رو دنبال میکنیم و همیشه جواب داده چرا باید دنبال راه دیگهای بگردیم ؟
جونیورهای تیم رو نگه دارید؛ چونیور درست و خوب تیم رو آپدیت نگه میداره. | 4 758 |
