چطوری میشه با بنچمارک دروغ گفت ؟
SpacetimeDB
اینکار رو برای شما کرده

ویدئو بالا رو چندساعت پیش دوستان برام فرستادند (من به Postgres18 خیلی علاقمند شدم بخاطر اضافه کردن Async هرچند هنوز نتونستم کامل تستش کنم)

نشستم ویدئو رو دیدم؛‌ ویدئو 56K بازدید داشته 4.7K لایک و 642 تا کامنت که همه هم مثبت بوده

من تموم کامنت‌هارو چک نکردم ولی خیلی‌هاش نظر مثبت هست.
جالبی قضیه اینجاس هیچکس متوجه تفاوت توی نحوه بنچمارک گیری نشده یعنی واقعا ؟

چیزی هم که ادعا می‌کنه که SpacetimeDB می‌تونه نقش سرور رو هم بازی کنه؛ از Postgres15 من یادم هست که دارند این کار رو بصورت جدی انجام میدند ملت باهاش.

پس داستان چیه ؟ عدد سازی .
اومدم روی گیت‌هاب issue بسازم و بگم که تکنینک مقایسه درست نیست که دیدم یک نفر دیگه اینکار رو کرده.

توی ویدئو اول دقیقه 10 به بعد رو ببینید؛ تمام تست‌هایی که انجام میده
client + server + db
هست؛ ولی وقتی به دیتابیس خودشون میرسه.
client + db
هست بعد از بررسی گیت‌هاب حتی متوجه شدم برای همه کلاینت روی typescript هست ولی برای خودشون روی Rust نوشته شده با خوندن بیشتر اوضاع بدتر هم شد. علاوه بر اینکه پروتوکل‌های متفاوتی استفاده شده و ...
تمام فلگ‌های optimization مربوط به کلاینت Rust رو که برای بنچمارک خودشون فقط استفاده می‌کنند تا ماکزیمم بالا بردند.

هیچ چیزی جز یک عددسازی بزرگ به ذهنم نمیرسه.
حالا شخصی که روی Github به این موضوع اشاره کرده بود اومده یک ویدئو هم براش ساخته (داشتم میگشتم ببینم کسی دیگه هم فهمیده این موضوع رو یا نه ویدئو رو پیدا کردم)
توی این ویدئو نشون میده که SpacetimeDB حتی با تمام optimization هایی که انجام داده توی شرایط برابر به Postgresql با کانفیگ دیفالت هم نمیرسه

Video on Youtube


پینوشت: خواستم بگم مثل این دوستی که ویدئو SpacetimeDB رو برای من فرستاد شما تو تله نبوفتید.

#موقت

بنظرم این رو شما هم باید ببینید؛ که از بحث‌های آینده که فلان دیتابیس چقدر خوبه پیشگیری کنیم.

تو دنیای opensource هم دروغ شاخ دار نگید. تابلوئه و سریعا هم لو میره!

اگر مثل من نیاز دارید با عزیزان و خانواده خارج از ایران تماس داشته باشید و اون‌ها رو از نگرانی در بیارید:

https://xn--r1a.website/ProxyMTProto
https://xn--r1a.website/vmessorg
https://xn--r1a.website/invoProxy


این کانال‌ها و مواردی که قبلتر معرفی کرده بودم متصل هستند.
سرعت بسیار ضعیف هست، اگر متصل شدید زودتر خبر سلامتی بدید و از نگرانی در بیاریدشون ♥️

نوروز مبارک 🤗🎉🎊

From April 24 onward, your interactions with GitHub Copilot—including inputs, outputs, code snippets, and associated context—may be used to train and enhance AI models unless you opt out.

کوپایلت از ۴ اردیبهشت از دیتاهای شما برای ترین استفاده خواهد کرد، اگر نمی‌خواید:

1) Go to GitHub Account Settings
2) Select Copilot
3) Choose whether to allow your data to be used for AI model training

از ۱۶ مارس تا امروز که ۳ آپریل هست
تصمیم گرفتم بجای اینکه خودم رو درگیر vpn کنم کتاب بخونم.

با این وضعیت اینترنت که کلا کار کردن درش تخته‌‌اس، توی بخش هوش مصنوعی هم که اندازه حداقل یک سال تلاش تا همینجا عقب افتادیم (که قطعاً بیشتر هم میشه) کلی هم که خبر تعدیل و لغو پروژه دارم می‌شنوم از دوستان.

خلاصه؛ دیدم جز اعصاب خوردی و ... چیزی برام نداره کلا همه چیز رو کنار گذاشتم و نشستم به یادگیری ولی جالب‌ترین کارش این بود که تعداد صفحاتی که هرروز می‌خونم رو یکجا یادداشت کردم تا ببینم فقط اگه درگیر vpn نباشم چقدر وقت می‌ذارم برای کتاب خوندن، که دیدم توی همین ۱۹ روز (با امروز) ۵۵۸ صفحه کتاب خوندم.

جدای از موارد دیگه که ویدئویی دارم یاد میگیرم، خلاصه گفتم همین ۱ ساعت وقتی هم که برای وصل شدن vpn روزانه میذارم رو بیخیال بشم.

و ازین سوشال مدیا خدافظی کنم برای مدتی!

به امید روزای بهتری که همه منتظرش پیر شدیم. 🌹

کلا پیشنهاد می‌کنم سمت کارهایی که اینترنت نیاز دارند نیاید، بخصوص برنامه‌نویسی.
دیوونه می‌شید.

بازم مرام نت‌بلاکس حداقل صدای ماها هست.
نهادهای دولتی‌ شبکه و اینترنت که همه خفه‌خون گرفتن.

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

Youtube Link (MrWhoseTheBoss)

خواستم بگم اینا باعث شدند که اینترنت طبقاتی داریم الان

بعد سگ و شغال میومدند می‌گفتند برای امنیت اینترنت رو قطع کردند.

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

مغز عرررزشی جماعت رو با تاپاله گاوی پر کردن

اینترنت آزاد برای همه باید باشه
اینترنت مهمترین ابزار برای پیشرفت هست
اینترنت مهمترین ابزار برای یادگیری هست

برای بچه‌هایی که طبقه اجتماعی (درآمدی) پایین‌تری دارند اینترنت بهترین ابزار برای یادگیری و داشتن آینده بهتر هست.

ولی عرررزشی پدرسگ زبون نفهم، انقدر خر بود که باعث شد این ابزار فقط از قشر ضعیف‌تر (مالی) جامعه گرفته بشه.

یک راهکار این هست که داکر ایمیج رو از یک دوستی که قبلتر pull کرده بگیرید.

چون دیدم دوستان خودم این روش رو بلد نیستند گفتم اینجا هم بذارم:

سناریو اینطوری هست.
من روی registry شخصی خودم این image رو نداشتم و برای راه‌اندازی پروژه یکی از دوستان بهش نیاز داشتم، بعد از تماس با دوست دیگری متوجه شدم اون‌ها هفته قبل موفق به pull کردن این ایمیج شدند و من اینطوری image رو برداشتم فرض کنیم مثلاً postgres:18 رو لازم داشتم

روی سروری که ایمیج رو داشتند (بله من از دوستانم دسترسی مستقیم به سرور میگیرم)

docker save postgres:18 | gzip > postgres_dockerimg.tar.gz

بعد این فایل رو با scp از سرور به سیستم خودم، و از سیستم خودم به سروری که ایمیج رو نداشت منتقل می‌کنم و این دستور رو روی اون سیستم میزنم :

docker load < postgres_dockerimg.tar.gz

و تمام حالا image رو روی این سرور دارم و می‌تونم به کارم ادامه بدم، اگر لازم شد می‌تونید با docker tag اسم و اطلاعات image رو تغییر بدید.


پینوشت :

یک توصیه امنیتی، اگر image رو از کسی یا جایی گرفتید که بهش اعتماد ندارید (۹۹.۹٪ بهتره اعتماد نداشته باشید)

اول این دستور رو وارد کنید:

docker image inspect --format='{{.Id}}' postgres:18

خروجی این باید یک sha256 باشه.
وارد سایت hub.docker.com بشید (گفتم که سایت کند باز می‌شه ولی pull نمیده چون کلودفلیر بسته‌اس) ایمیج مدنظر رو و تگ درستش رو پیدا کنید وارد جزئیات که بشید
Index Digest
رو گذاشته باید با چیزی که توی ترمینال دیدید یکسان باشه.
اگر نبود image دستکاری شده و بهتره باهاش کانتینر اجرا نکنید.

یادآوری کنم:

نه بنده و نه هیچ کدوم از کانال‌های بنده روی هیچ یک از پلتفرم‌های ایرانی اکانت نداره و نخواهد داشت.

ویدئویی، متنی یا ...

Designing Data-Intensive Applications
یکی از کتاب‌های مورد علاقه من هست؛ وقتی نسخه اول این کتاب منتشر شد من هم بسیار درگیر سیستم‌هایی بودم که دیتای زیادی داشتند و BigData بخشی از کارم بود.

خوندن این کتاب دریچه جدیدی رو برام باز کرد و الان که فکر می‌کنم کتاب سنگینی بود؛ حالا چرا الان این رو می‌گم ؟

قبل از اتفاقات اخیر کمک یکی از دوستان قدیمی می‌کردم که تازه (۲ سال) هست وارد دنیای برنامه‌نویسی بعنوان شغل شده و چندوقتی رو درگیر یک سری مشکلات پروژه‌اش بوده؛ بعد از اینکه کمکش کردم مشکلش حل شد ازم پرسید این موارد رو از کجا یاد گرفتی و چطوری می‌تونم یاد بگیرم ؟
منم این کتاب رو بهش معرفی کردم.

امروز دوباره پیام داد (ایران نیستند) و بعد از صحبت از کتاب گفت که بسیار خوندنش سخت هست براش؛ برای خیلی از سنیورها هم درک این موضوعات سخت هست بطور کلی این کتاب کتاب آسونی نیست هرچند همه چیز ساده بیان شده.

همینطوری که داشتم فکر می‌کردم چطوری می‌شه این کتاب رو برای دیگران ساده کرد و پروسه یادگیری خودم رو مرور می‌کردم ( همون روش ویدئو ببین و تخمه بشکون : ویدئو اول یوتیوب pyhints )

به ذهنم رسید همین کار رو برای این کتاب هم میشه کرد؛ ولی خب این کتاب ویدئویی براش وجود نداره.

این شد که به هوش مصنوعی رو آوردم بدون اینکه لذت خوندن کتاب رو از کسی بگیریم ازش خواستم کتاب رو تبدیل به پادکست کنه اما توی کل پادکست باید همه چیز با مثال پیش بره و خیلی ساده و روان باشه.

برای منی که این مباحث رو اکثرا کار کردم بنظرم خیلی ساده اومد؛ شما هم گوش بدید ببینید چطور هست ؟

بنظرتون اینکار و پادکست کردن فصل به فصل کتاب‌ها ادامه بدم یا نه ؟

البته باقی پادکست‌ها رو توی این کانال نخواهم گذاشت؛ چون کانال رو پر می‌کنه.

اول این سمپل پادکست رو گوش بدید و بعد کتاب رو بخونید ساده‌تر می‌شه قضیه برای شما هم ؟

آیا این بخش پادکست به اندازه کافی مباحث رو ساده توضیح داده ؟

پینوشت: reaction بزنید روی پست متوجه ‌میشم ادامه بدیم یا نه؛ البته شخصا اینکار رو ادامه خواهم داد. چون وسط هرکاری می‌تونم این پادکست رو گوش بدم.

یکی به من پیام داده، توهین نکرده ولی خوبم صحبت نکرده:

همه چیز رو سخت می‌کنی الکی،
من ۶ ماهه بعنوان برنامه‌نویس شروع به کار کردم
نه این کتابارو خوندم، نه چیزایی که تو کانال pyhints گفتی رو بلدم.
ولی همه‌ی کارامم دارم انجام میدم
با دوره فلانی هم همرو یاد گرفتم، برو ازون یادبگیر همه چیز رو ساده می‌گیره

مکالمه من :

+ شرکت و پروژه شما چندتا برنامه‌نویس و چقدر کاربر داره ؟
- ۱۱ نفریم، ۲۰۰۰ تا هم کاربر داریم.

+ حقوق شما چقدر هست ؟
- حدوداً ۲۳م

+ هروقت شرکتی ایرانی با تورم امروز قبول کرد بابت کاری که می‌کنی بهت حداقل ۶ برابر یا بیشتر حقوق بده، اون موقع متوجه شدی که چرا کتاب خوندی و مفاهیم رو فهمیدی.

اما اگر بخوام برای همه توسعه دهنده‌های دیگر توضیح بدم؛ باید با این جمله که همیشه به بچه‌های توی تیمم می‌گم شروع کنم :

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

به خیلی از تکنولوژی‌های امروز فکر کنید؛ اگر نخوندید برید ببینید همشون از دل مشکلات در اومدند
Hadoop, Kafka, Spark, Docker, K8s, ...

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

مثال بزنم :
چند مدت پیش یک توسعه دهنده بر اساس یکی از انیمیشن‌ها یک سایت خیلی ساده نوشته که یک مارمولک وسط صفحه هست و وقتی روی اون کلیک می‌کنی می‌گه Lizard
بعد خیلی معروف شد و ملت درخواست دادند counter جهانی براش بسازه

ببین دیگه ازین اپلیکیشن ساده‌تر و بی‌خطر تر وجود نداره؛ نه تراکنش مالی داره و نه یوزر پولی داده و نه هیچی ...

طرف اول همه درخواست‌ها رو توی فایل می‌ریخته؛ سایت دان میشه
همرو میریزه توی دیتابیس؛ سایت کند میشه (تعداد req/sec بیش از حد بالا بوده)
شروع می‌کنه سرورهای بزرگتری رو خریدن؛ از ۴ دلار به ۶۰ دلار میرسه هزینه ماهانه سرور ولی مشکل همچنان پا برجاس و مسئله این بوده که با این مفهوم که write های کوچیک و زیاد روی دیتابیس داره بهش آسیب میزنه آشنا نبوده.

چون مشکل رو نمی‌شناخته؛ سراغ راه حل اشتباه رفته.

درنهایت بر می‌گرده و شروع به optimize کردن کد می‌کنه؛ الان سایت روی همون هاست ۴ دلاری بالاس و تا این لحظه

2,146,829,700

کلیک رو ثبت کرده (البته خیلی از کلیک‌ها رو از دست داده)

ایشون وقتی تونست راه‌حل رو پیدا کنه که دیگران مشکلاتش رو بهش گفتند؛ اگر این یک بیزینس خصوصی با کاربرای واقعی بود سرور 5,000 دلاری هم نجاتش نمی‌داد (چون راه اشتباه بود) و امکان داشت با وجود هزینه بسیار بالا بهترین مشتری‌هاش رو هم از دست بده.

شرکت‌هایی با محصولات خوب اینطوری از دور خارج می‌شوند؛ من شاهد این موضوع بودم (حداقل ۱۰ نفر شما برای سورس کد پروژه‌های شرکت‌هاتون من رو دعوت به همکاری دادید تا مشکل حل کنم و خب به هر دلیلی با مدیرعامل به توافق نرسیدیم)‌

توی تمام کانال‌ها من هدفم آموزش مقدمات نیست (البته غیر از Rust که خودم داشتم Syntax یاد می‌گرفتم)‌ بلکه هدفم این بوده که شما حداقل یک بار هر مشکلی رو ببینید و اگر اون الگو رو توی کار واقعی دیدید بتونید قبل از down شدن سرویس‌ها شناساییش کنید.

وگرنه برای یادگرفتن یک framework فقط ۲-۳ ساعت آموزش کافی هست.

راستی اون سایت هم :
https://lizard.click/

#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.

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

توی پست مربوط به رودمپ بکند :
Backend Roadmap
برای آخرین مورد گفتم که حتما همه‌ی بچه‌ها باید از روز اول ADR بنویسند؛ سر این موضوع با هیچ کدوم از بچه‌ها شوخی ندارم.

اما خیلی‌ها (مثل بچه‌هایی که باهاشون کار می‌کنم) پرسیدید چرا باید ADR بنویسیم بهتر نیست وقتمون رو روی کد زدن و تمرین و یادگیری بذاریم.

جواب کوتاه:
هیچ ابزار - هیچ کتاب و ... دیگری به اندازه نوشتن ADR شمارو تست نمی‌کنه و به شما یاد نمی‌ده حتی.

اما اگر توضیحات برای قانع شدن می‌خواید ادامه مطلب رو بخونید:

بخش بزرگی از کار یک مهندس نرم‌افزار (بخصوص توی سطوح بالاتر) یادگیری بحث و مناظره کردن هست؛ چیزی که توی سال‌های اخیر همکاریم با بچه‌ها توی ایران خیلی خیلی کم دیدم. این بحث‌ها اکثرا سر چه چیز‌هایی هست ؟
۱- از کدوم فریمورک استفاده کنیم
۲- با کدوم استاندارد پیش بریم
۳- دیتابیس چی بذاریم
۴- تست نویسی چطوری باشه
۵- چرا از این ابزار استفاده کنیم یا نکنیم
و ...

شما هرروز درگیر این بحث‌ها خواهید بود و اینکه بتونید از پیشنهادات خودتون بطور منطقی دفاع کنید موضوع بسیار بسیار مهمی هست.
وقتی شروع به نوشتن
ADR = Architecture Decision Records
می‌کنید یاد می‌گیرید ابزاری که دارید انتخاب می‌کنید رو همه جنبه‌هاش رو ببینید؛ خیلی وقتا ابزارهایی که افراد انتخاب می‌کنند فقط بخاطر hype هست و جو زده هست اون انتخاب بدون اینکه بدونند آیا واقعا بدردشون میخوره یا مناسب کارشون هست.
خیلی وقتا این مکالمه رو شنیدیم:

- چرا فلان ابزار رو انتخاب کردید ؟
+ گوگل داره ازین استفاده می‌کنه؛ چی ازین بهتر
آره دوست من ولی گوگل چندین میلیارد کاربر داره و تو به زور به ۵ هزارتا میرسی.
گوگل هزاران نفر توسعه دهنده داره ولی تیم تو به زور به ۱۰ نفر میرسه.
گوگل میلیاردها دلار خرج زیرساخت و دستمزد و ... میده.
تو زیرساختت به زور ۱۰۰ هزار دلار میشه.

برای خود من موقع بحث سر موضوعاتی که بچه‌ها باید یاد بگیرند برای توسعه بکند همین موضوع پیش اومد یکی از بچه‌ها گفت برای سرویس ارسال ایمیل از celery استفاده کنیم پس اینم بنویسید؛ که اگر نگاه کنید من ممنوع کردم استفاده‌اش رو celery سرویس بسیار بزرگ و سنگینی هست.
برای پروژه‌های کوچیک اشتباه هست که توی قدم اول برید سراغش؛ اما اگر کسی بتونه ADR خوب بهم بده قطعا قبول می‌کنم.

درسته وقتی تنهایی کد میزنید به ADR نیازی نیست اما نوشتنش باعث میشه یاد بگیرید بحث کنید؛ توی نوشتن ADR معمولا شما به چندتا ابزار میرسیدو باید این چیزها رو توضیح بدید :

۱- این ابزارها برای چه کاری هستند و چرا فکر می‌کنید توی پروژه لازمشون داریم ؟
۲- چرا هرکدوم از ابزارها رو در نظر گرفتید؟ (چرایی مهم هست)
۳- انتخاب شما کدوم بوده ؟ و البته چرا ؟
۴- نقاط قوت و ضعف ابزاری که انتخاب کردید چی هست ؟
۵- نقاط قوت و ضعف ابزارهایی که انتخاب نشدند چی هست؟
۶- تحت چه شرایطی ابزارهای دیگر رو انتخاب می‌کردید یا اینکه شرایط پروژه چی بود که نقاط قوت ابزار انتخابی شما به باقی موارد و البته نقاط ضعف اون چربید و انتخاب شد.

فکر می‌کنم از سوال‌ها مشخص باشه که چقدر چیز مفید و مهم رو درک می‌کنید و یاد میگرید.
آیا همه پروژه‌ها این رو دارند ؟
به جرات میگم که بیش از ۹۲-۹۳٪ پروژه‌ها و حتی شاید توسعه دهنده‌ها حتی نمی‌دونند چی هست؛ ولی تمام پروژه‌ها و تمام مدیران فنی و اعضای تیم‌هاشون هرروز درگیر یکی از این تصمیم گیری‌ها هستند.

به مدیرای فنی هم پیشنهاد می‌کنم توی تیم این موضوع رو داشته باشید؛ خیلی وقتا نیرو احساس می‌کنه حرف‌هاش شنیده نمی‌شه درصورتی که شما می‌دونید چیزی که پیشنهاد می‌کنه خوب نیست برای پروژه فقط وقت برای توضیح دادن بهش رو ندارید.
معمولا با نوشتن ADR خیلی از بچه‌ها خودشون متوجه می‌شوند که چرا جواب نه بهشون داده شده.

موقت :

کانال قبلی چون ریپورت شده بود، این موارد رو مجدد فرستادم برای دوستانی که علاقمند هستند.

فکر کنم فقط همین دو مورد بود 🤔
برای رودمپ بکند