چطوری System Design رو یاد بگیریم قسمت ۱ از ۲

داشتم یه مقاله از 📱 میخوندم با عنوان چطوری System Design رو یاد گرفتم. اول بریم سراغ این مقاله و آخر کارم منابعی که قبلا توی کانال معرفی کردم رو بهشون لینک میدم.

نویسنده ی مقاله که سفر یادگیریش رو باهامون به اشتراک میذاره میگه زمانی بود که هر ویدیو یا بلاگی که اسم «طراحی سیستم» (System Design) روش بود رو کلاً بی‌خیال می‌شده و با خودش میگفته اینا مال سنیور هاست نه من. بعد میره تو مصاحبه بهش میگن برای طراحی یه اپ مثل Uber باید چیکار کرد.

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

اینجاس که System Design وارد میشه.

---

1️⃣ اول از همه حالا که میدونیم چیو نمیدونیم بریم یادش بگیریم

طراحی سیستم اولش خیلی ترسناکه.

آدما یه سری کلمه میگن مثل «شاردینگ» (Sharding)، «CQRS»، «متوازن‌کننده بار» (Load Balancer)، (Eventual Consistency) و...

همه اولش احساس گم شدن دارن.

طراحی سیستم یه موضوع تکی نیست. یه «فصل» نیست که بتونی تو یه هفته تمومش کنی.

بلکه ترکیبی از ایناست:

✔️ جریان حرکت داده‌ها چطوریه؟

✔️ سرویس‌ها چطور با هم صحبت می‌کنن؟

✔️ چطور سیستم‌ها زیر بار ترافیک سنگین دوام میارن؟

✔️ و چطور می‌شه سیستم رو قابل‌اطمینان، سریع و مقاوم در برابر خطا (Fault-tolerant) ساخت؟

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

---

2️⃣ «طراحی سیستم» رو به موضوعات کوچیک تقسیم کنیم

طراحی سیستم یه موضوع بزرگ نیست، بلکه مجموعه‌ای از بلوک‌های ساختمانی به هم پیوسته است.

بریم برای نقشه راه:

الف) اصول اولیه (The Basics)

✔️ وقتی توی مرورگر یه آدرس (URL) رو تایپ می‌کنی، چه اتفاقی می‌افته؟

✔️ مفاهیم DNS، متوازن‌کننده بار (Load Balancer) و CDN چی هستن؟

✔️ پروتکل TCP در برابر UDP، HTTP در برابر HTTPS

ب) داده و ذخیره‌سازی (Data and Storage)

✔️ دیتابیس SQL در برابر NoSQL

✔️ ایندکسینگ (Indexing)، رپلیکا (Replication)، شاردینگ (Sharding)

✔️ کی باید MongoDB رو انتخاب کنی و کی PostgreSQL؟

ج) تکنیک‌های مقیاس‌گذاری (Scaling Techniques)

✔️ مقیاس‌گذاری افقی (Horizontal) در برابر عمودی (Vertical)

✔️ کشینگ (Caching) (مثل Redis، Memcached)

✔️ متوازن‌سازی بار (Load Balancing) (مثل Round-robin، IP Hashing)

این بخش باعث میشه چیزی رو طراحی کنید که برای میلیون‌ها کاربر کار کنه، حتی اگه فقط روی کاغذ باشه.

د) الگوهای معماری (Architecture Patterns)

✔️ مونولیت (Monolith) در برابر میکروسرویس‌ها (Microservices)

✔️ معماری مبتنی بر رویداد (Event-Driven Architecture)

✔️ مفاهیم Pub/Sub، صف‌های پیام (Message Queues) (مثل Kafka، RabbitMQ)

---

3️⃣ تماشای تفکر آدم‌های واقعی، نه فقط آموزش دادن اون‌ها

به جای دیدن ویدیوهایی که سبک آموزشی دارن، شروع کنید به دیدن مصاحبه‌های شبیه‌سازی‌شده (Mock Interviews).

و باور کنید، این کل قضیه رو عوض میکنه.

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

کانال‌هایی که خیلی کمک کننده میتونن باشن:

🎞 یوتیوب Gaurav Sen: توضیح دادن از صفر و اساس

🎞 یوتیوب Exponent: مصاحبه‌های شبیه‌سازی‌شده با کاندیداهای واقعی

🎞 یوتیوب ByteByteGo: رویکرد بصری و قصه‌گویی‌شون

بهتون یاد میده چطور:

✔️ سؤالات درست و شفاف‌کننده بپرسید.

✔️ نیازمندی‌های عملکردی (Functional) و غیرعملکردی (Non-functional) رو تعریف کنید.

✔️ مراحل طراحی API، انتخاب پایگاه داده و منطق مقیاس‌گذاری رو توضیح بدید.

✔️ و همیشه در مورد مبادله‌ها (Tradeoffs) صحبت کنید، نه فقط انتخاب‌ها.

—-

⬅️ هنوز تموم نشده و ادامه در قسمت بعدی

💡 تا قسمت بعدی مثل همیشه کنجکاو بمونید :)

🆔 @MdDaily

چطوری System Design رو یاد بگیریم قسمت ۲ از ۲

قسمت اول

خب خب بریم برای برای ادامه‌ی مسیر: از طراحی روی کاغذ تا آموزش دادن به بقیه

4️⃣ شروع کن به رسم، حتی اگه روی کاغذ باشه!

یه چیزی که خیلی کمک کنندس: رسم کردن (Drawing) هستش.

ما آرتیست نیستیم. ولی وقتی فلو کار رو از

دیتایبیس → اپ های سرور → لود بالانسر ها → کلانیت

رسم میکنیم تازه دیدمون باز میشه.

وقتی رسم میکنیم:

✔️ فلو درخواست واقعی به نظر می‌رسه.

✔️ میبینیم که Bottlenecks کجاها ممکنه اتفاق بیفته.

✔️ میفهمیم که کش (Cache) رو کجا بذاریم یا کِی از صف (Queue) استفاده کنیم.

هرجا گیر میکنم فقط یه قلم و کاغذ برمیدارم و شروع میکنم به رسم تا دیدم باز تر بشه و اون افکار پراکندم مرتب بشه. پیشنهاد میکنم نوشتن با ماژیک رو شیشه رو هم امتحان کنید، خیلی جوابه :)

5️⃣ با حل کردن مسئله‌های واقعی تمرین کنید

وقتی توی اصول اولیه مطمئن شدید، دست از تماشا کردن بردارید و رسم کردن رو شروع کنید.

این روش تمرینی میتونه کمکتون کنه:

✔️ یه سیستم واقعی انتخاب کنید: واتساپ، یوتیوب، اسنپ‌فود، اینستاگرام.

✔️ اول نیازمندی‌های عملکردی (Functional Requirements) رو بنویسید (سیستم باید چیکار کنه).

✔️ بعد نیازمندی‌های غیرعملکردی (Non-functional Requirements) رو اضافه کنید (مقیاس‌پذیری، دسترس‌پذیری، تأخیر).

✔️ یه تخمین اولیه بزنید (تعداد کاربر، QPS، حجم DB).

✔️ یه معماری سطح بالا (High-level Architecture) طراحی کنید.

🚀 حالا وقت عمیق تر شدن رسیده:

✔️ DB schema
✔️APIs
✔️ Scaling strategies
✔️ Handling failures (مدیریت خطا ها)
✔️ Edge Cases (حالت های خاص)

با رسم هفته ای یه طرح شروع کنید و نه فقط یک راه‌حل، بلکه چندین احتمال مختلف.

چون توی مصاحبه‌ها و کارهای واقعی، به ندرت یه جواب کامل وجود داره. مهم اینه که بتونی توجیه کنی چرا X رو به Y ترجیح دادی.

6️⃣ وقت واقعی کردن رسیده

🔴تئوری تا وقتی پیاده نشه، بی‌فایده‌ست.

بذارید از تجربه خودم بگم. تویه شرکت داشتیم رو یه سیستمی کار میکردیم که به صورت میکروسرویس پیاده شده بود با Go و برای ارتباط داخلی سرویس ها از GRPC استفاده کرده بودیم. اوایل برای سرویس آنالیتیکس از MongoDB استفاده کرده بودیم. اما با زیاد شدن حجم داده ها و کوئری ها (رکورد ها به قدری زیاد بودن که حجم دیسک دیتابیس شده بود 15 گیگ) سیستم شروع کرد به کند شدن. یه راهکار ها این بود که بیایم چنتا نود مختلف بیاریم بالا ولی پیچیدگی ایش زیاد بود، پس شروع کردیم به R&D کردن دیتابیس هایی که به نظر برای این کار مناسب بودن. بعد از تست های اولیه و گرفتن بنچمارک متوجه شدیم که clickhouse میتونه توی مورد ما این بخش از پروژه رو نجات بده. تیم بکند دور هم جمع شدیم و فقط یه ماژیک برداشتیم و ساعت ها روی شیشه سیستم دیزاین های مختلفیو رسم و بررسی کردیم و دیدمون باز شد و در نهایت طرح نهایی. حالا که همه چیز حداقل روی کاغذ اماده بود و کار میکرد باید مهاجرت رو شروع و سیستم جدید رو پیاده میکردیم. در نهایت با یه بررسی درست، بررسی سیستم دیزاین های مختلف و داشتن دید کلی و جزئی از سیستم ، به جایی رسیدیم که میلیون ها داده رو بدون مشکل آنالیز کردیم و نزدیک Real time خروجی نشون میدیم. بعد آروم آروم رفتیم جلو و چیز های دیگه هم مثل RabbitMQ اضافه کردیم. اره الان پروژه بزرگ شده ولی این پروژه ی بزرگ حاصل قدم های کوچیکی بود که برداشتیم ولی نکتش اینکه اگه میخواستیم به آخرش فکر کنیم که همچین چیز بزرگی چطوری قراره ساخته بشه هیچ وقت شروع نمیشد :)

7️⃣ شروع کنید به یاد دادن به بقیه

این آخرین مرحله هست.

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

هر بار که یه چیزی رو توضیح میدم اینو میفهمم که:

اگه بتونم خیلی ساده اون رو درس بدم، پس واقعاً خوب فهمیدمش.

درنهایت طراحی سیستم شعبده‌بازی نیست.

فقط کافیه:

✔️ از اصول اولیه شروع کنید.

✔️ به موارد استفاده‌ی دنیای واقعی فکر کنید.

✔️ یه ساختار برای خودتون بسازید.

✔️ هفته‌ای تمرین کنید.

✔️ پشت هر انتخابتون بپرسید «چرا»؟

✔️ و آروم‌آروم بهتر بشید.

حتی اگه روزی ۳۰ دقیقه هم وقت بذارید، بعد از ۳ ماه تفاوت رو می‌بینید.

حرف آخر: قضیه جواب‌ها نیست، قضیه رویکرده!

توی طراحی سیستم، اغلب احساس عدم اطمینان خواهید کرد. این طبیعیه.

چیزی که مهمه اینه که چطور به یک مسئله نزدیک می‌شید.

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

با «یک URL چطور کار می‌کنه؟» شروع کنید و به طراحی اینستاگرام ختم کنید.

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

—-

💡 مثل همیشه کنجکاو بمونید :)

🆔 @MdDaily

میخواستم بک گراندم رو عوض کنم و دنبال یه جایی بودم که کلی بک گراند خوب و رایگان داشته باشه، پس توی ریپو های گیت هاب سرچ کردم و رسیدم به پروژه lwalpapers . حدودا ۳ سالی هست که اپدیت نشده ولی ۱۰۰۰ تا بک گراند یونیک رو توی خودش جمع آوری کرده.

آدرس وبسایت:

🔗 https://wallpaper.castorisdead.xyz/

—-

💡 مثل همیشه کنجکاو بمونید :)

🆔 @MdDaily

داشتم یه مقاله فوق‌العاده از یه تجربه عملیاتی سنگین می‌خوندم با عنوان: «چطور یک میلیارد رکورد رو از DB1 به DB2 جابجا کردیم؛ بدون Downtime» 🚀

نویسنده مقاله (و تیمش) با یه چالش بزرگ روبرو بودن: دیتابیس قدیمیشون که دیتای حساس مالی (پرداخت، سفارش و...) رو نگه می‌داشت، از ۱ میلیارد رکورد رد شده بود و به شدت کند شده بود, Queryهایی که ثانیه‌ای طول می‌کشید، `Batch Job`ها (کارهایی که دسته‌ای مثل تسویه حساب‌ها) ساعتی طول می‌کشید. Scale کردن (افزایش مقیاس) دیگه جواب نمی‌داد و باید مهاجرت می‌کردن، اونم بدون حتی یک ثانیه Downtime (قطعی).

این خلاصه‌ی قدم‌به‌قدم کاریه که انجام دادن:

1️⃣ جابجایی دیتای قدیمی (Bulk Migration)

برای انتقال Cold data (دیتای قدیمی که دیگه تغییر نمی‌کنه)، نیومدن یه Dump (فایل خروجی) گنده بگیرن. به جاش:

✔️ جدول رو بر اساس رنج Primary Key (کلید اصلی جدول) به Chunk (تکه‌های کوچیک دیتا) تقسیم کردن.

✔️ موقع بارگذاری، ایندکس‌های ثانویه و `Constraint`ها (قیدها) رو غیرفعال کردن (تا سرعت Insert (ثبت دیتا) بالا بره).

✔️ چندتا ورکر رو Parallel (موازی) برای انتقال این تیکه‌ها ران کردن.

✔️ بعد از انتقال هر تیکه، یه Checksum (یه جور کد محاسباتی برای چک کردن یکی بودن دیتا) می‌گرفتن تا مطمئن بشن دیتا دقیقاً کپی شده.

2️⃣ مدیریت ترافیک زنده (Dual Writes)

چالش اصلی، دیتای جدیدی بود که همزمان با مهاجرت داشت وارد می‌شد.

✔️ اپلیکیشن رو طوری تغییر دادن که Dual Writes (نوشتن همزمان در دو دیتابیس) انجام بده (یعنی هر دیتای جدید رو همزمان هم تو دیتابیس قدیمی و هم تو دیتابیس جدید بنویسه).

✔️ برای اینکه مطمئن بشن دیتایی گم نمی‌شه، اگه نوشتن تو دیتابیس جدیده خراب می‌شد، اون رویداد (event) رو می‌نداختن توی یه `Retry Queue` کافکا (صفی برای کارهای شکست‌خورده که باید دوباره امتحان بشن).

✔️ یه Consumer (سرویسی که از صف کافکا دیتا می‌خونه) جدا اون صف رو می‌خوند و اونقدر تلاش می‌کرد تا بالاخره تو دیتابیس جدیده هم ثبت بشه.

✔️ برای جلوگیری از تکراری ثبت شدن دیتا (موقع تلاش مجدد)، همه‌ی نوشتن‌ها رو با آیدی یکتا Idempotent (یعنی اگه یه کاری رو چند بار هم اجرا کنی، نتیجه نهایی یکی باشه) کرده بودن.

3️⃣ تست پنهانی در پروداکشن (Shadow Reads)

خب، دیتاها سینک بودن. ولی آیا دیتابیس جدیده زیر بار واقعی جواب می‌داد؟

✔️ اینجا از Shadow Reads (خوندن پنهانی از دیتابیس جدید برای تست) استفاده کردن.

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

✔️ این کار باعث شد کلی باگ ریز ولی حیاتی رو پیدا کنن که تو تست‌ها معلوم نمی‌شد: مثلاً تفاوت رفتار Timezone ها (منطقه‌های زمانی)، تبدیل `NULL`ها (مقادیر پوچ) به مقادیر پیش‌فرض، و تفاوت در Collation (قواعد مرتب‌سازی و مقایسه متن‌ها) (که باعث می‌شد مرتب‌سازی نتایج فرق کنه).

4️⃣ لحظه جابجایی نهایی (The Cutover)

روز Cutover (لحظه جابجایی کامل و سوییچ کردن)، ریسک اصلی این بود که Cache (حافظه موقت) دیتابیس جدیده «سرد» (Cold) بود و اولین کوئری‌ها ممکن بود خیلی کند باشن.

✔️ قبل از سوییچ، با اجرای کوئری‌های مصنوعی، کش دیتابیس جدید رو Pre-warm (گرم کردن کش با دیتای الکی) کردن.

✔️ ساعت ۴:۳۰ صبح (کمترین ترافیک) با زدن یه Feature Flag (یه جور کلید نرم‌افزاری برای روشن/خاموش کردن قابلیت‌ها)، همه‌ی Read ها (خوندن‌ها) رو به سمت دیتابیس جدید فرستادن. (برای اطمینان، Dual Writes رو هنوز روشن نگه داشتن تا راه برگشت امن داشته باشن).

5️⃣ رصد کردن (Observability) 📊

نویسنده میگه چیزی که واقعاً نجاتشون داد، SQL خفن نبود، بلکه Observability (قابلیت رصد کامل سیستم) بود. اونا وسواسی همه‌چیز رو مانیتور می‌کردن:

✔️ با Replication Lag (میزان عقب بودن دیتابیس‌های کپی از دیتابیس اصلی)

✔️ با `Deadlock`ها (وقتی دوتا پروسه قفل منتظر هم می‌مونن)

✔️ با Cache Hit Ratio (درصدی از دیتا که از کش خونده می‌شه نه از دیسک)

✔️ با شمارنده‌ی عدم تطابق نتایج در Shadow Reads

✔️ و از همه مهم‌تر: `KPI`های بیزینسی (شاخص‌های کلیدی عملکرد مثل سفارش در دقیقه).

ما چی می تونیم یاد بگیریم؟ 💡

مهاجرت‌های بزرگ، یه «مسئله دیتابیسی» نیستن، بلکه یه «مسئله System Design (طراحی سیستم)» هستن.

شما یه میلیارد ردیف رو یهو جابجا نمی‌کنید، بلکه batch امن به batch امن»، «ورودی WAL (فایلی که دیتابیس قبل از هر کاری، تغییرات رو اول اونجا می‌نویسه) به WAL» و «Checksum به Checksum» این کار رو می‌کنید.

در نهایت: Zero Downtime (قطعی صفر) شانسی نیست؛ طراحیه.

—-

💡 مثل همیشه کنجکاو بمونید :)

🆔 @MdDaily

تا حالا فکر کردید وقتی تو «اسنپ» یا «گوگل مپس» مبدأ و مقصد رو می‌زنید، چطوری تو یه چشم به هم زدن «بهترین» مسیر رو از بین این همه کوچه و خیابون پیدا می‌کنه؟

یا مثلاً تو یه بازی کامپیوتری، اون هوش مصنوعی (AI) دشمن چطوری انقدر قشنگ شما رو پیدا می‌کنه و کوتاه‌ترین راه رو برای رسیدن بهتون انتخاب می‌کنه؟

اینا همشون دارن یه مسئله‌ی معروف به اسم «پیدا کردن کوتاه‌ترین مسیر» (Shortest Path) رو حل می‌کنن. تو این پست میخوایم بریم سراغ دوتا از غول‌های حل این مسئله: دایکسترا (Dijkstra) و اِی-اِستار (A*).

1️⃣ الگوریتم دایکسترا (Dijkstra): کاوشگرِ وظیفه‌شناس (ولی کور!)

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

چطوری کار می‌کنه؟

✔️ از نقطه‌ی شروع (Source) کارش رو شروع می‌کنه.

✔️ یه «صف اولویت» (Priority Queue) داره. کارش اینه که در هر مرحله، گرهی (node) رو برای بررسی انتخاب می‌کنه که کمترین هزینه (cost) رو از مبدأ داشته باشه.

✔️ این الگوریتم «کور» (Uninformed) ـه. یعنی چی؟ یعنی اصلاً نمی‌دونه مقصد کجاست! 😅

✔️ در نتیجه، جستجوش به صورت «یکنواخت» (مثل Uniform Cost Search) پخش می‌شه. کارش اینه که به صورت سیستماتیک کوتاه‌ترین مسیر از مبدأ به همه‌ی نقاط دیگه رو حساب کنه تا اینکه بالاخره اتفاقی به مقصد ما هم برسه.

نتیجه این روش چیه؟

مزیت: اینه که تضمین می‌کنه کوتاه‌ترین و بهینه‌ترین مسیر رو پیدا می‌کنه (بهش میگن Optimal)، البته به شرطی که وزن منفی (negative weight) تو گراف نداشته باشیم (مثلاً راهی که به جای هزینه داشتن، بهت زمان اضافه کنه!).

عیب: چون «کوره» و نمی‌دونه هدف کجاست، کلی زمان و انرژی صرف بررسی گره‌هایی می‌کنه که اصلاً در جهت مقصد نیستن. (مثلاً می‌خوای از تهران بری شمال، این بنده خدا همزمان مسیرهای به سمت اصفهان رو هم چک می‌کنه، چون شاید یه راه عجیبی از اونجا باشه!).

2️⃣ الگوریتم A* (A-Star): کاوشگرِ هوشمند (و هدفمند)

اِی-اِستار (A*) نسخه‌ی باهوش‌تر و «زرنگ»ترِ دایکستراست. می‌تونیم بگیم A* همون دایکسترای خودمونه، فقط یه «قطب‌نما» یا «GPS» هم دستش گرفته.

چطوری کار می‌کنه؟

✔️ اِی-استار هم مثل دایکسترا، هزینه‌ای که واقعاً تا الان طی کرده (یعنی مسافت واقعی از مبدأ تا گره فعلی) رو حساب می‌کنه. (ریاضیش رو بخوامی بگیم g(n)).

✔️ اما، برگ برنده‌اش اینجاست: اون یه «حدس هوشمندانه» (Heuristic) هم می‌زنه که چقدر فکر می‌کنه تا مقصد مونده. (ریاضیش رو بخوامی بگیم h(n)).

هیوریستیک یعنی چی؟

خیلی ساده‌ست: در مسیریابی، بهترین هیوریستیک همون «فاصله خط صاف» خودمونه. یعنی تو نقشه یه خط صاف از جایی که هستی تا مقصد بکشی.

✔️ پس اِی-استار در هر قدم، میره سراغ گرهی که مجموعِ «هزینه واقعی تا اینجا» + «هزینه تخمینی تا مقصد» (f(n) = g(n) + h(n)) از همه کمتر باشه.

نتیجه این هوشمندی چیه؟

مزیت: چون «آگاه» (Informed) هست و یه «حس جهت‌یابی» داره، جستجوی خودش رو مستقیم می‌بره به سمت هدف. دیگه الکی همه‌جا رو نمی‌گرده و در نتیجه خیلی خیلی سریع‌تره و گره‌های (nodes) کمتری رو بررسی می‌کنه.

عیب (یا نکته مهم): همه‌چی به «خوب» بودن اون حدس (Heuristic) بستگی داره. اگه هیوریستیک شما «قابل قبول» (Admissible) نباشه (یعنی بدبین باشه و فاصله رو بیشتر از حد واقعی حدس بزنه)، A* ممکنه گول بخوره و اصلاً جواب بهینه (Optimal) رو پیدا نکنه!


💡 خب، ما چی یاد گرفتیم؟ (Dijkstra vs A*)

دایکسترا: «کور»ـه و جستجوش (UCS) در تمام جهات پخشه. هدفش پیدا کردن کوتاه‌ترین راه از مبدأ به همه‌ی نقاطه.

اِی-اِستار: «هوشمند»ـه و با کمک هیوریستیک به سمت هدف می‌گرده. هدفش پیدا کردن کوتاه‌ترین راه از مبدأ به یک مقصد مشخصه.

حالا یه نکته:

الگوریتم دایکسترا در واقع یه حالت خاص از الگوریتم A* هست!

چطوری؟ اگه توی A*، اون «حدس هوشمندانه» (h(n)) رو برای همه‌ی گره‌ها صفر در نظر بگیری (یعنی عملاً بگی: «آقا من هیچ حدسی ندارم!»)، الگوریتم A* دقیقاً تبدیل می‌شه به دایکسترا!

پس کی از کدوم استفاده کنیم؟

برو سراغ Dijkstra:

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

برو سراغ A*:

* وقتی یک مبدأ و یک مقصد مشخص داری (۹۹٪ کاربردهای ما مثل GPS، مسیریابی تو بازی‌ها، رباتیک و...).

* وقتی سرعت برات مهمه و می‌تونی یه هیوریستیک خوب (مثل فاصله خط صاف) حساب کنی.

دفعه‌ی بعدی که «نشان» رو باز کردید یا تو یه بازی مثل The Last of Us دیدید که دشمن چقدر هوشمندانه دنبالتون میاد، یادتون باشه که یه چیزی شبیه A* پشت صحنه داره کار می‌کنه.

—-

💡 مثل همیشه کنجکاو بمونید :)

🆔 @MdDaily

حالا که همه جا صحبت از AI و اخبارشه، بیاید یه لحظه ترمز کنیم و یه ابزار کاربردی متفاوت رو یاد بگیریم.

تا حالا شده بخواید یه پروژه شخصی (Side Project) رو تست کنید، یه نمونه‌کار بیارید بالا یا صرفاً یه وبسایت برای خودتون داشته باشید، ولی نمی خواهید برای دامین (Domain) هزینه کنید؟
یا شایدم رفتید سراغ دامین‌های رایگان ولی دیدید همشون ساب‌دامین (Subdomain) هستن و حسابی تو ذوق میزنن؟

امروز میخوایم بریم سراغ یه پروژه اوپن‌سورس به اسم DigitalPlat Domain.
شعارشون خیلی جذابه: «دامین رایگان برای همه»

🌐 داستان چیه؟

پروژه DigitalPlat Domain یه حرکت غیرانتفاعی (Nonprofit) هست که توسط The Hack Foundation پشتیبانی میشه. هدفشون اینه که دسترسی به وب رو برای همه راحت‌تر کنن. برخلاف خیلی از سرویس‌های دیگه که اولش رایگانن و بعد پول میخوان، این پروژه واقعاً رایگانه.

🛠 چه ویژگی‌هایی داره که به درد ما میخوره؟

✔️ دامین واقعی، نه ساب‌دامین: اینجا خبری از آدرس‌های طولانی و زشت نیست. شما دامین‌هایی با پسوند‌های خاص مثل .US.KG ، .DPDNS.ORG یا .QZZ.IO میگیرید.
✔️ کنترل کامل DNS: این خیلی مهمه! شما می‌تونید دامینتون رو به سرویس‌های مدیریت DNS محبوب مثل Cloudflare متصل کنید.
✔️ بدون هزینه‌های مخفی: نه هزینه ثبت داره، نه هزینه تمدید سالانه.
✔️ امنیت و اعتماد: چون اوپن‌سورسه و پشتش یه موسسه خیریه معتبره، نگرانی کمتری بابت پریدن دامین یا سوءاستفاده وجود داره.

💡 کجا به کارمون میاد؟

✔️ وقتی میخوای یه پروتوتایپ (Prototype) سریع بیاری بالا.
✔️ برای پروژه‌های دانشجویی و آموزشی.
✔️ ساختن بلاگ شخصی یا پورتفولیو بدون هزینه.
✔️ تست کردن تنظیمات سرور و شبکه قبل از خرید دامین اصلی.

🚀 چطوری بگیریم؟
کافیه برید توی دشبورد سایتشون، اسم دامین مد نظرتون رو سرچ کنید و اگه خالی بود، ثبتش کنید و DNS ها رو ست کنید.

🔗 لینک پروژه و داشبورد:

https://dash.domain.digitalplat.org/


🔗منبع پست:

https://www.opensourceprojects.dev/post/1959600649026302372



—-

💡 مثل همیشه کنجکاو بمونید :)

🆔 @MdDaily

تولدمون مبارک باشه 🎁

امروز MdDaily در کنار تک تک شما عزیزان ۳ ساله شد ❤️

ایده ی کانال از کجا اومد؟

تویه گروه دوستانه بودیم و راجب چیزایی که میخوندم اونجا مینوشتم و همین انگیزه ای شد که تصمیم بگیرم تجربه هام و چیزایی که راجبشون میخونم رو تو یه جای عمومی تری منتشر کنم

اسم Md از کجا اومد؟

خب اسم خودم ماهان عه، گفتم ایول بذار Mahan رو با Developer ترکیب کنم

مخففش میشه Md و اینجوری شد که Md Daily خلق شد :)


برای فصل جدید کانال خوشحال میشم نظرات و پیشنهادات شما رو بدونم :)

و در اخر قدردان تک تک شما عزیزان هستم که با وجودتون قلب md daily میزنه 🫶

وقتی عشق به کد زدن ته می‌کشه: قصه تلخ برن‌آوت (Burnout)

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

اکثراً فکر می‌کنن برن‌آوت یعنی فقط خستگی وحشتناک یا اضطراب شدید. اینا هستن، ولی نشونه‌ی اول معمولاً ساده‌تر و موذی‌تره: چیزی که قبلاً عاشقش بودی، دیگه بهت حال نمیده. واسه خیلی از ما دولوپرها، کد زدن فقط شغل نیست؛ عشقه. ولی وقتی این حس عوض میشه و کد زدن میشه یه «وظیفه»، یه «زور» یا صرفاً «فشار کار»، یعنی زنگ خطر به صدا دراومده.

نقطه جوش: وقتی مغز شات‌دان می‌کنه

ددلاین‌ها که روی هم تلنبار می‌شن، اوضاع بیریخت‌تر میشه. خسته بیدار میشی، خسته می‌شینی پشت سیستم، آخر شب هم جنازه‌تری. این فقط خستگی جسمی نیست؛ یه پوچیِ ذهنیه. ادیتور رو باز می‌کنی، زل می‌زنی به کدها ولی دریغ از یه ذره حس؛ نه ایده‌ای، نه جرقه‌ای، نه اون غریزه همیشگی. مغزت رسماً خالیه.

تله‌ی «برنامه‌نویسِ سریع و خفن»

برنامه‌نویسا همش می‌خوان ثابت کنن که سریع و قابل اعتمادن. این ویژگی خوبیه، ولی می‌تونه تبدیل بشه به یه تله‌ی خطرناک. وقتی نشون بدی که سریعی، حس می‌کنی مجبوری همیشه سریع بمونی و کم‌کم «فشار» میشه حالتِ دیفالت تو. فول‌-استک کار کردن، راضی نگه داشتن کلاینت‌ها و تحویل مداوم فیچرها، همه‌ش با هم میشه حس دائمی «غرق شدن».

فشار تکنولوژی و فرهنگی که باهات روراست نیست

دولوپرها دائماً با «سندروم ایمپاستر» درگیرن. فشارِ اینکه باید مدام چیز یاد بگیری و با فریم‌ورک‌های جدید آپدیت باشی، واقعاً سنگینه. مقایسه کردن خودت با بقیه هم که قاتلِ حال‌خوبه. مشکل فرهنگِ «بهره‌وری سمی» (Toxic Productivity) و مقایسه‌ست که زیرپوستی اونایی رو که تا مرز ذوب شدنِ مغز کار می‌کنن، تشویق می‌کنن.

راه واقعی برگشت (چی جواب میده، چی نه)

چیزی که می‌تونه جلوی این سقوط آزاد رو بگیره، «دیسیپلین» نیست؛ استراحت مطلقه.

چی واقعاً کمکت می‌کنه؟

✔️ دوری کامل از اسکرین: مانیتور، لپ‌تاپ، گوشی؛ همه رو بذار کنار.

✔️وقت گذروندن با آدمای واقعی: برو پیش رفقا و خانواده.

✔️بازگشت به تنظیمات کارخانه: برو سراغ تفریحات غیردیجیتالِ قدیمی.

✔️کارای غیرمفید: کارایی بکن که اصلاً قرار نیست خروجیِ خاصی داشته باشن.

چی کمک نمی‌کنه؟

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

ریکاوری شدن مثل دکمه‌ی خاموش/روشن نیست؛ یه ریست (Reset) آرومه که زمان می‌بره.

درسی که گرون تموم میشه

اگه می‌شد با گذشته حرف زد، باید به اون برنامه‌نویسی که تا پاسی از شب بیداره گفت: «آقا/خانم! مرخصی بگیر. حتی اگه عاشقِ کارتی. مخصوصاً اگه عاشقِ کارتی.» عاشقِ کار بودن تو رو ضدضربه نمی‌کنه، آسیب‌پذیرترت می‌کنه؛ چون مرزِ بین «اشتیاق» و «فشار» واسه عاشقای کار خیلی راحت گم میشه.

نشونه اصلی: وقتی تفریحت شروع کرد بهت حسِ «شغل» دادن، وقتشه بکشی کنار.

نقش تیم‌ها و شرکت‌ها

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

چندتا راهکار واسه اینکه کم نیاری

واسه دوام آوردن تو این مسیر، تغییرات کوچیک خیلی اثر دارن:

✔️ به محض دیدن اولین نشونه‌ها، واقعی استراحت کن.

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

✔️ جای اینکه هشدارهای اطرافیان رو ایگنور کنی، بهشون گوش بده.

✔️ واسه کم کردن بار ذهنی، همه چی رو نوت‌برداری کن.

ختم کلام: این یه باگ نیست، فیچره!

برن‌آوت «لوس‌بازیِ کارهای پشت‌میزنشینی» نیست. این قضیه ربطی به خستگیِ تایپ کردن نداره؛ بحثِ فشار ذهنی، انتظارات غیرواقعی، بحران هویت و حس همیشگیِ «عقب موندن از تکنولوژی»ـه. این فشار واقعیه و می‌تونه حتی عاشق‌ترین برنامه‌نویس‌ها رو هم از پا دربیاره.

اگه عاشقِ کدنویسی هستی، مجبور نیستی ۲۴ ساعته بدوی دنبالش. به خودت اجازه بده استراحت کنی و دیسکانکت شی. بذار اشتیاقت نفس بکشه. اگه واقعاً عاشقش باشی، لازم نیست به زور نگه‌ش داری؛ وقتی بهش فضا بدی، خودش برمی‌گرده.

—-

💡 مثل همیشه کنجکاو بمونید :)

🆔 @MdDaily

کد تمیز افسانه نیست؛ فقط دوام نمیاره

مشکل این نیست که هیچ‌کس کد تمیز نمی‌نویسه.
مشکل اینه که کد تمیز تو پروژه‌های واقعی، زیر فشارِ کار کم‌کم داغون میشه.

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

✨ اصلاً کد تمیز یعنی چی؟

کد تمیز یه چیز کاملاً سلیقه‌ای نیست. بعضی چیزاش واضحه: اسم متغیر و فانکشن باید درست باشه، هر تیکه کد باید کار خودش رو بکنه، وابستگی‌ها نباید قاطی‌پاطی باشن و بشه راحت تغییرش داد بدون اینکه کل سیستم بریزه به هم.
البته همه‌چیز هم قانون خشک نداره. کدی که امروز تمیزه، ممکنه چند ماه دیگه فقط قابل تحمل باشه.

تعریف ساده‌ش اینه: کدی که تغییر دادنش از نوشتنش کم‌هزینه‌تره.

🖥 پروژه‌ها از اول داغون نیستن، داغون میشن.

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

🖥 پروتوتایپی که قرار نبود بمونه.

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

🖥 ریفکتوری که تموم نمیشه.

اگه یه تمیزکاری سال‌ها طول کشیده، معمولاً مشکل از کد نیست. یا تست ندارین، یا معلوم نیست مسئول این بخش کیه، یا همه می‌ترسن دست بزنن چیزی خراب بشه. ریفکتور وقتی به کار واقعی وصل نباشه، میشه کاری که همیشه هست ولی هیچ‌وقت تموم نمیشه.

سنیور سخت‌گیر همیشه خوب نیست.

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

راه‌حل‌های موقت، وقتی دائم میشن دردسر می‌سازن.

یه هک سریع یا فلگ موقتی بعضی وقتا لازمه. مشکل وقتی شروع میشه که اسم درست نداره، کسی نمی‌دونه چرا هست، و معلوم نیست کی باید حذفش کنه. اون موقع میشه یه تیکه خطرناک که همه ازش فرار می‌کنن.

🤖 هوش مصنوعی کد زشت نمی‌نویسه، کد بی‌مسئولیت می‌نویسه.

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

📊 بیزنس و کد دشمن هم نیستن.

بیزنس می‌خواد زنده بمونه، برنامه‌نویس می‌خواد سیستم نخوابه. نه سرعت بدون فکر جواب میده، نه وسواس بیش از حد. کدی که نشه راحت تغییرش داد، بیزنس رو کند می‌کنه. بیزنسی هم که به کد اهمیت نده، بعداً هزینه‌شو میده.

🤔 پس بی‌خیال کد تمیز بشیم؟ نه.

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

🔗 برای نوشتن این پست از این منبع خیلی الهام گرفته شده:
https://dev.to/sylwia-lask/nobody-writes-clean-code-we-all-just-pretend-11d1

—-

💡 مثل همیشه کنجکاو بمونید :)

🆔 @MdDaily

🥳🎆 یلدای پارسی خجسته🌟🤩

✨به بهانه یلدای باستانی و این سنت زیبای پارسی، پارس پک یه مسابقه با حال گذاشته و قراره هدایای جذابی تقدیمتون کنه🎁

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

با توجه به نتیجه بازی هم بهت میگه کدوم شخصیت ایران باستان هستی و روش های دیگه ای هم برای افزایش شانس قرعه کشی هستش🆙

⭕️ برای شرکت در قرعه کشی هم تا ۵ دی ماه فرصت داری

⚔️پس زودتر پیکار رو شروع کن:

👉شروع پیکار

☕️راستی چون جایزه ها مرتبط با قهوه و اسپرسو هستن، این پستو بفرست برای اون دوستت که مثل شب یلدا به کافئین نیاز داره تا یک دقیقه هم شده بیشتر بیدار بمونه☕️

بیشتر چت‌بات‌ها وقت آدم رو با تعارف و جواب‌های الکی طولانی تلف می‌کنن. این دوتا پرامپتی که نوشتم رو حدود یک ماهه دارم استفاده می‌کنم؛ باعث میشه مدل بره سر اصل مطلب، صادقانه‌تر جواب بده و دست از «راضی نگه داشتن» برداره.

می‌تونید یکی از این چنتا رو بسته به نیازتون توی بخش Custom Instructions در ChatGPT یا قسمت System Instructions در Gemini بذارید.

🤖 اگه میخواین مدل صادق و رک باشه:

From now on, be completely honest and ruthless. Do not give compliments, flattery, ass-kissing, or polite phrasing. The tone does not matter; be blunt, direct, even harsh. If something is wrong, tell me clearly and mercilessly. If a question is unclear or information is missing, ask directly and do not guess. Only give the truth and solutions, with no emotions, pleasantries, or extra sentences. Do not sugarcoat anything; speak the truth unfiltered. Tell it like it is.

🤖 اگه میخواین مدل صادق باشه و جواب های مشخصی بهتون بده:

Be brief, blunt, and truth-maximizing. Ruthless about correctness. Natural and conversational.

Hard constraints: No self-introduction. No explaining your role. No meta commentary. No invitations to interact like “ask me”, “you can try”, or “would you like”. No politeness rituals, compliments, apologies, or tone softening. Exception: if the user greets you (for example “سلام” or “hi”), reply with a single-word greeting in the same language and nothing else.

Rules: Accuracy over agreeableness. Do not mirror my framing or assume I’m right. If my premise is wrong, start with “Premise wrong:” and correct it in one sentence. No hedging words. If uncertain, output “Unknown:” followed by exactly what would verify it. Write in clear, human, conversational language. Short sentences. No robotic structure. Response length is dynamic. Write only what is necessary to improve the outcome. When giving opinions or reviews, prioritize actionable criticism over denoscription.

Output format must follow the input language exactly. If the user writes in Persian, use only one of these labels: پاسخ: اصلاح: نیاز: مقایسه:. If the user writes in English, use only one of these labels: Answer: Fix: Need: Tradeoff:. Pick exactly one label. No other headings.

Language rule: Respond in the same language as the user’s input. Technical terms must appear in English first, followed by the meaning in parentheses in the user’s language.

Do not expand scope unless explicitly asked.

🤖 اگه میخواین مدل بین قضاوت و تحلیل بالانس برقرار کنه با حفظ لحن پاسخ صریح:

Be direct and truth-first. Ruthless about correctness. Talk like a normal human, not a manual.

Hard rules: No self-introduction. No explaining your role. No meta talk. No invitations to interact. No politeness rituals, flattery, apologies, or softening language.

Core rule: Correctness beats agreeableness. Don’t mirror my framing and don’t assume I’m right. If my premise is wrong, start with “Premise wrong:” and correct it in one sentence. No hedging. If something is unknown, say “Unknown:” and state exactly what would make it knowable.

Depth control: Be concise, but never shallow. Let the problem decide the depth. For judgment or opinion, give the conclusion first, then only the reasons that matter. For analysis, include every necessary layer—no more, no less. No padding. Every sentence must earn its place.

Writing style: Clear, simple, conversational. No corporate tone. No filler.

Output format: Match the input language exactly. Use exactly one label.
Persian: پاسخ: اصلاح: نیاز: مقایسه:
English: Answer: Fix: Need: Tradeoff:

Language rule: Respond in the user’s language. Technical terms first in English, then their meaning in the user’s language.

—-

💡 مثل همیشه کنجکاو بمونید :)

🆔 @MdDaily

💡💡💡💡💡💡💡💡
🍸🍿. ❤️❤️❤️.   🍿🍸
🍉🍉🍉🍉🍉🍉🍉🍉


داشتم فکر میکردم به مناسبت یلدا چه متنی بنویسم، دیدم نیاز به پیچدگی خاصی نیست پس مستقیم میگم یلداتون مبارک و همیشه لبتون خندون باشه ❤️🫶

- ماهان

—-

💡 امشب یک دقیقه ییشتر کنجکاو بمونید :)

🆔 @MdDaily

اصلاً من متخصّصم یا نه؟ شاید نکته اصلی همینه! 🤔

داشتم یه مقاله به اسم I Don't Know If I'm An Expert (And That Might Be the Point) می‌خوندم که نویسنده مقاله داستان رو از جایی شروع می‌کنه که همه‌مون ممکنه توش گیر کرده باشیم. اون یه شرکت امنیت سایبری داره، کلی مدرک معتبرِ جهانی تو جیبشه و حتی شش تا کتاب هم نوشته . اما می‌گه وقتی داشتم رزومه‌م رو پر می‌کردم و به بخش «تخصص‌ها» رسیدم، یهو خشکم زد! نه اینکه چیزی بلد نباشم، نه؛ مشکل اینجاست که می‌گه: «من هر روز دارم یه چیز جدید یاد می‌گیرم و همین باعث شده از خودم بپرسم: اصلاً من متخصصِ چیزی هستم یا نه؟» 🤯

---

تله‌ای به اسم «مطمئن بودن» ⚠️

حقیقتش اینه که ما توی دنیایی زندگی می‌کنیم که انگار مجبوریم همه‌ش ادای «آدم‌های همه‌چیز‌دون» رو دربیاریم. نویسنده می‌گه: «من می‌تونم برم توی دفتر یه مشتری و براشون خفن‌ترین سیستم‌های دفاعی رو طراحی کنم، اما آگاهانه واژه متخصص رو برای خودم به کار نمی‌برم.» چرا؟ چون توی دنیای تکنولوژی، وقتی می‌گی «مطمئنم»، یعنی یادگیری رو متوقف کردی. و این شروعِ سقوطِ مهارته 📉.

دقت کردین؟ یه برنامه‌نویس تازه‌کار با یه دوره دو روزه می‌نویسه «متخصص ری‌اکت»؛ یا یکی دیگه با دو تا سخنرانی می‌شه «رهبر فکری». نویسنده معتقده این تورمِ مدارک و القاب، باعث شده واژه متخصص بی‌معنی بشه. این نمایشِ «قطعیت»، مثل یه نقابه که نمی‌ذاره بقیه بفهمن ما هنوز چقدر چیزها رو نمی‌دونیم 🎭.

معیار واقعی چیه؟ ✨

نویسنده یه پیشنهاد باحال داره. می‌گه به جای اینکه بپرسیم «من متخصصم؟»، بیایم این چندتا سوال رو از خودمون بپرسیم تا همزادپنداری‌مون با واقعیت بیشتر بشه:

⬅️ آیا این کار رو اون‌قدر تکرار کردم که سوراخ‌سمبه‌هاش رو بشناسم؟

⬅️ آیا خروجی کارم توی دنیای واقعی (نه فقط روی کاغذ) جواب داده؟

⬅️ آیا کسی حاضر هست بابت تجربه‌ قبلی‌م، دوباره بهم پول بده؟

⬅️ می‌تونم این موضوع رو جوری به بقیه یاد بدم که واقعاً بفهمن؟

خودِ نویسنده با همین معیارها می‌گه: «من توی امنیتِ کسب‌وکارهای کوچیک کارم درسته، چون امتحان پس دادم. اما مثلاً توی بحث‌های سنگینی مثل کوبرنتیز، با اینکه خیلی‌ها ممکنه بگن متخصصی، ولی خودم می‌دونم که هنوز راه دارم.»

پارادوکسِ عجیبِ یادگیری 🌀

نکته قشنگِ حرفش اینجاست: «هرچی بیشتر می‌فهمم، کمتر احساس تخصص می‌کنم.» این یه جور پارادوکسه، ولی دقیقاً همینه که نشون می‌ده تو واقعاً بلدی! تازه‌کارها فکر می‌کنن تهِ کوه رو دیدن، ولی حرفه‌ای‌ها می‌دونن که این مسیر تمومی نداره. نویسنده می‌گه: «اگه یه پزشک بگه من بعد دانشگاه دیگه هیچی یاد نگرفتم، فرار نمی‌کنی؟ خب توی دنیای فنی هم همینه. تواضع فکری نشونه بی‌سوادی نیست؛ نشونه اینه که تو می‌فهمی چقدر بازی جدیه.» 🎯

حرف آخر: نمایش رو تموم کنیم ✋

حرف حسابش اینه: بیایم به جای اینکه با کلمات قلمبه‌سلمبه رزومه‌مون رو پر کنیم، با «خروجی‌هامون» حرف بزنیم. به جای اینکه بگیم «من متخصص هوش مصنوعی‌ام»، بگیم «من مدل‌های ML رو برای انطباق در حوزه سلامت با دقت ۹۹.۷٪ در طول ۱۸ ماه پیاده‌سازی کردم».

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

—-

💡 مثل همیشه کنجکاو بمونید :)

🆔 @MdDaily