🔵 عنوان مقاله
Automating from Console with AI Assistance

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

🟣لینک مقاله:
https://cur.at/PGplUR3?m=web

➖➖➖➖➖➖➖➖
👑 @software_Labdon

یکی از مشکلات بزرگ کتب برنامه‌نویسی  همیشه این بوده که موضوع Encapsulation رو به شکلی تدریس کرده‌اند که انگار موضوعی است که فقط و فقط مختص به OOP هست؛ و از اون بدتر، این موضوع رو جوری جا انداختن که افراد فکر میکنند Encapsulation یعنی همان Access modifiers ها (private,public).

برای همین هست که بیشتر افراد هیچگونه تصوری از این ندارند که Encapsulation خارج از OOP چگونه است، و حتی در همون پارادایم OOP هم بدرستی نمیتونن کپسوله سازی رو پیاده سازی کنن و اجزای مختلف کدهاشون درهم و برهم هست.

موضوع Encapsulation یک موضوع منطقی است و برعکس چیزی که بیشتر کتاب‌ها بهتون میگن ربطی به Access modifier ها ندارد. Access modifier ها صرفا یک برچسب هستند که به طور عمده دو وظیفه رو دنبال میکنن:  یک اینکه کامپایلر بتواند جلوی اشتباهات سهوی شما در بکارگیری  برخی فیلدها رو بگیره (که این مدل اشتباه فوق العاده نادر هست)؛ و دلیل دیگر اینکه سایر برنامه‌نویس‌ها موقع خواندن کدها، متوجه منظور شما بشن. مثلا متوجه بشن که شما خواسته ات در هنگام نوشتن کد این بوده که خارج از فلان محدوده از فلان فیلد استفاده نشود.

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

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

متاسفانه برخی زبان‌های معروف OOP مثل جاوا یا سی پلاس پلاس، تا سال‌ها یک سیستم ماژول درست حسابی نداشتند و باعث شدند Access modifier ها در ذهن برنامه‌نویس‌ها مترادف با Encapsulation و کدهای ماژولار بشوند؛ به این شکل که در نبود اون‌ها، اصلا هیچ تصوری از اینکه Encapsulation چیست و قرار است طی آن چه اتفاقی بیفتد ندارند!

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

<Amirreza Gh/>

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

▪️اگه داری برنامه نویسی رو یاد میگیری یا دنبال کار میگردی و‌ مصاحبه میری این چیت شیت ها( برگه تقلب ها) گزینه های خیلی خوبی هست برای مرور...

▪️تقریبا اکثر زبان ها و ابزارهارو پوشش میده و میتونی استفاده کنی ؛ نکته جذابش اینه که پرکابرد ترین پرامپت های ChatGPT هم داره :))

آدرس سایت:

Quickref.me

🔵 عنوان مقاله
What's NEW in Playwright? 13 Must-Know Features You Should Be Using

🟢 خلاصه مقاله:
این مطلب یک مرور ۱۶ دقیقه‌ای از جوآن اسکویول مونترو را معرفی می‌کند که ۱۳ قابلیت جدید و مهم پلی‌رایت را به‌صورت خلاصه و کاربردی توضیح می‌دهد. این مرور برای تسترها و توسعه‌دهندگانی است که می‌خواهند سریع و عملی با به‌روزرسانی‌ها آشنا شوند و بدانند هر قابلیت در پروژه‌های واقعی چه مزیتی دارد—از بهبود پایداری و ساده‌تر شدن خطایابی تا تسریع فرایندها. نتیجه آن یک جمع‌بندی موجز و مفید است تا بتوانید به‌سرعت اولویت دهید کدام قابلیت‌ها را زودتر به کار بگیرید.

🟣لینک مقاله:
https://cur.at/oPHJk1q?m=web

➖➖➖➖➖➖➖➖
👑 @software_Labdon

🔵 عنوان مقاله
How to Test LLMs, AI Assistants & Agents — The Future of QA

🟢 خلاصه مقاله:
این مقاله به‌جای استفاده از هوش مصنوعی برای تست نرم‌افزار، بر پرسش دشوارتر تمرکز می‌کند: چگونه خودِ سامانه‌های هوش مصنوعی—مانند مدل‌های زبانی، دستیارها و ایجنت‌ها—را به‌طور دقیق آزمایش کنیم؟ در گفت‌وگوی الکس خواستوویچ و ایگور دوروفسکیخ، توضیح داده می‌شود که چرا روش‌های سنتی QA برای سیستم‌های احتمالی و غیردترمینستیک کافی نیستند و باید کیفیت را در ابعادی مانند قابلیت اتکا، وفاداری به واقعیت، ایمنی، هم‌راستایی با قصد کاربر، و مقاومت در برابر پرامپت‌های خصمانه سنجید.

آن‌ها به چالش‌هایی چون تعیین معیار «درستی» پاسخ، رگرسیون بین نسخه‌های مدل، و توازن میان خلاقیت و تکرارپذیری اشاره می‌کنند و مجموعه‌ای از رویکردها را طرح می‌کنند: دیتاست‌های مرجع و تست‌های رفتاری، ردتیمینگ، ارزیابی با روبریک یا مقایسه زوجی، بنچمارک‌های آفلاین در کنار A/B تست آنلاین با گاردریل‌ها، و بازبینی انسانی برای موارد مرزی. همچنین بر آزمایش انتهابه‌انتها برای ایجنت‌ها (برنامه‌ریزی، استفاده از ابزار، بازیابی از خطا) و پایش مداوم در تولید تأکید می‌شود.

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

🟣لینک مقاله:
https://cur.at/6J2eaHV?m=web

➖➖➖➖➖➖➖➖
👑 @software_Labdon

🔵 عنوان مقاله
Global Cache: Make Playwright BeforeAll Run Once for All Workers

🟢 خلاصه مقاله:
این مقاله نشان می‌دهد که چرا beforeAll در اجرای موازی تست‌های Playwright کافی نیست، چون معمولاً برای هر فایل یا هر کارگر اجرا می‌شود و باعث تکرار تنظیمات پرهزینه می‌گردد. نویسنده، ویتالی پوتاپوف، راهکاری عملی پیشنهاد می‌کند: یک کش سراسری سفارشی که فقط یک‌بار تولید می‌شود و همه کارگرها از آن استفاده می‌کنند. با این کار، اقلامی مثل توکن‌های احراز هویت، داده‌های اولیه یا متادیتای محیط فقط یک‌بار ساخته و سپس بین کارگرها به اشتراک گذاشته می‌شوند. او به محل نگهداری کش (حافظه، فایل، یا گام globalSetup)، مدیریت هم‌زمانی برای جلوگیری از رقابت کارگرها و پاکسازی درست منابع اشاره می‌کند. نتیجه، تست‌هایی سریع‌تر، پایدارتر و قابل پیش‌بینی‌تر در اجرای موازی است.

🟣لینک مقاله:
https://cur.at/yMncNKn?m=web

➖➖➖➖➖➖➖➖
👑 @software_Labdon

🔵 عنوان مقاله
One team, one goal: The reality of introducing a unified testing strategy

🟢 خلاصه مقاله:
سام فارندل و جینا چل‌تون روایت می‌کنند چگونه از پراکندگی ابزارها و تعریف‌های متفاوت کیفیت به یک راهبرد یکپارچه آزمون رسیدند. آنها با شنیدن مسائل تیم‌ها، مجموعه‌ای از اصول مشترک مانند آزمون مبتنی بر ریسک، شیفت-چپ، هرم آزمون و سنجه‌های کیفیت واحد تدوین کردند و با حداقل استانداردها، ابزارهای پیشنهادی، خط لوله‌های CI/CD و حاکمیت سبک، تعادل بین خودمختاری تیم‌ها و یکپارچگی سازمانی را برقرار ساختند. اجرای تدریجی با پایلوت‌ها، آموزش، جامعه‌های عمل و داشبوردهای شفاف، تردیدها را کاهش داد و به بهبود سرعت بازخورد، کاهش تست‌های ناپایدار و همکاری بهتر انجامید. جمع‌بندی آنها: بر اصول بجای نسخه‌های دستوری تکیه کنید، روی جامعه‌سازی و سنجه‌های معنادار سرمایه‌گذاری کنید و راهبرد آزمون را یک محصول زنده بدانید، نه یک پروژه مقطعی.

🟣لینک مقاله:
https://cur.at/xkT0Gqj?m=web

➖➖➖➖➖➖➖➖
👑 @software_Labdon

🚀 به دنیای توسعه و تکنولوژی خوش اومدی!

اگر به موضوعات زیر علاقه‌مندی:

🔹 Golang
🔹 Linux & DevOps
🔹 Software Engineering
🔹 AI & Machine Learning
🔹 فرصت‌های شغلی ریموت (خارجی و داخلی)

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

📌 از این لینک همه چنل‌هامونو یه‌جا ببین و جوین شو:

👉 https://t.iss.one/addlist/QtXiQlynEJwzODBk

🔵 عنوان مقاله
Implementing High Volume Automated Testing System

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

🟣لینک مقاله:
https://cur.at/7kwVpmm?m=web

➖➖➖➖➖➖➖➖
👑 @software_Labdon

تلگرام 12.0 و اضافه شدن Grok...پایان زودهنگام یک شراکت...؟!

▪️قرار بود تلگرام نسخه 12.0 رو همراه با ادغام Grok منتشر کنه، اما تا امروز (31 اوت 2025) هیچ تأیید رسمی‌ای نشده. به نظر میاد این توافق متوقف شده و هنوز قراردادی امضا یا اطلاعیه‌ای رسمی منتشر نشده.

▪️این موضوع احتمالاً یعنی Grok طبق برنامه وارد نسخه 12.0 نشده ، شاید به خاطر شکست مذاکرات، تغییر استراتژی یا تأخیرهای دیگه.

ا"Architecture Decision Record (ADR) Template" یعنی یک قالب (Template) برای ثبت و مستندسازی تصمیم‌های معماری نرم‌افزار.

به طور ساده:

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

یک ADR Template کمک می‌کند این مستندسازی همیشه با یک ساختار مشخص و یکسان انجام شود.

---

### ساختار رایج یک ADR Template

معمولاً شامل بخش‌های زیر است:

1. Title (عنوان تصمیم)
یک عنوان کوتاه و گویا.

2. Status (وضعیت)
مثلاً: Proposed, Accepted, Rejected, Superseded

3. Context (زمینه / دلیل نیاز به تصمیم)
توضیح اینکه چه مشکلی وجود داشته یا چه نیازی باعث شد که تصمیم گرفته شود.

4. Decision (تصمیم نهایی)
تصمیمی که گرفته شد (مثلاً "ما از PostgreSQL به جای MySQL استفاده می‌کنیم").

5. Consequences (پیامدها)
مزایا و معایب این تصمیم، و اثراتی که بر سیستم دارد.

---

### مثال ساده

# ADR 001: انتخاب دیتابیس اصلی

## Status
Accepted

## Context
ما نیاز به یک دیتابیس داریم که قابلیت ذخیره داده‌های ساخت‌یافته و مقیاس‌پذیری داشته باشد. تیم تجربه خوبی با SQL دارد.

## Decision
انتخاب PostgreSQL به عنوان دیتابیس اصلی.

## Consequences
+ ویژگی‌های پیشرفته (JSONB، Full-text search)
+ جامعه کاربری بزرگ
- یادگیری برخی قابلیت‌های خاص برای اعضای تیم جدید

➖➖➖➖➖➖➖➖
👑 @software_Labdon

نمونه سمپل برای استفاده توی پروژه هاتون
➖➖➖➖➖➖➖➖
👑 @software_Labdon

🟢 اگر کارفرما یا کارجو هستی

و دنبال نیرو یا موقعیت شغلی توی حوزه‌های زیر هستی، به من پیام بده 👇

⚔️ DevOps Engineer
⚔️ Site Reliability Engineer (SRE)
⚔️ Linux SysAdmin
⚔️ Cloud Engineer (AWS/GCP/Azure)
⚔️ Infrastructure Engineer
⚔️ Security Engineer (DevSecOps/Linux)
⚔️ Automation Engineer
⚔️ Platform Engineer
⚔️ Software Security
⚔️ Software QA
⚔️ Backend
⚔️ AI Engineer / Machine Learning
⚔️ Database Engineer / DBA

📩 همین الان پیام بده و استارت بزن! تا هم بتونی نیروی خوب پیدا کنی و یا یتونی یه موقعیت شغلی مناسب پیدا کنی

به من پیام بده آگهی یا رزومه ات رو قرار بدم اینجا

@mrbardia72

فیچر های ++C توی ورژن های 2020 2017 2014 2011 رو به صورت یه جا همشو اینجا جمع کردن با توضیح کوتاه و ساده:

https://github.com/AnthonyCalandra/modern-cpp-features

<Nimo/>

جدا از مهندسی پشت تلگرام که بهینه نوشته شده، تلگرام چیزی داره به اسم Update Queue. چیزی که ۱ سال از دوران جوونیم رو صرف مهندسی معکوسش کردم.
تلگرام برای پوش کردن تغییرات مثل پیام جدید، ادیت، ری اکشن، تایپینگ و… به کلاینت‌ها از سرویس Updates تو پروتکل MTProto استفاده میکنه، ایده ی کلی و کلیدی خیلی ساده اس و اینه که کلاینت ها یه state محلی نگه میدارن و آپدیتارو دقیقا با ترتیب درست اعمال میکنن؛ اگه شکافی بینشون افتاد، Difference می‌گیرن و دوباره پرش میکنن.

چرا اینکارو کرده و کلا چالشا چیه؟
• ترتیبش مهمه چون ممکنه یه اپدیت وابسته به چیزی باشه که توی خود همون پچ میاد
• تحویل دقیق باید انجام بشه و هیچی گم نشه
• مقیاسش هم میلیون‌ها کاربر همزمان باید بگیرنش، مثل کانال های بزرگ

از اونجایی که هر پیامرسان منبع عظیمی از اتفاقاتیه که هر لحظه میوفته ما میتونیم اسم این اتفاقات رو event بزاریم. تلگرام هم یه پیامرسان مولتی کلاینته، یعنی هر کاربر میتونه چندین دیوایس برای یه حساب داشته باشه، پس وقتی یه ایونت اتفاق میوفته که باید یه کاربر از اون خبردار بشه باید اون ایونت رو به دیوایس های دیگه ی کاربر هم بفرسته، حدودا با مرتبه زمانی On^2.

مکانیزم اینجوریه که وقتی دیوایسی انلاین باشه و سوکت همون سوکتی باشه که keep alive هست یا اخرین rpc رو کال کرده سرور ایونت رو توی queue برای اون دیوایس نگه نمیداره و مستقیم میفرسته به کلاینت، حالا از اونجایی که کلاینت های دیگه ممکنه افلاین باشن یا حتی توی بکگراند پروسسشون کیل شده باشه عقب میمونن. حالا وقتی اون دیوایسی که عقب مونده بود با باز شدن سوکتش درخواست گرفتن اپدیت هارو وقتی که افلاین بوده رو از سرور میکنه و اطلاعات لوکالش رو میفرسته به سرور، من برای ساده شدنش اینجوری میگم که دیوایس میاد به سرور میگه من تا این زمان t رو داشتم و بعد این رو بهم بده، سرور هم میاد حساب کتابش رو میکنه و جواب رو توی یه پچ میفرسته! حالا چی توی این پچ هست و چی رو میفرسته رو میتونم یه رشته توییت دیگه در موردش بزنم.

حالا اگه اعدادی که توی پچ میاد با اعداد توی کلاینت نخونه عملا میگیم گپ اتفاق افتاده، برای همین هم کلاینت باید رکویست getDiff رو بزنه.
رکویست updates.getDifference به کلاینت اجازه می‌ده بگه:
من الان pts = X و seq = Y هستم و هر چی بین این و حالت جدید هست بهم بده.
• سرور ممکنه جواب بده:
difference: همه ی آپدیت های گمشده
differenceSlice: بخشی از آپدیت ها یعنی هنوز باید به فچ کردن ادامه بدی
differenceEmpty: چیزی تغییر نکرده

جالبترش اینه که توی نسخه های جدیدترش برای کانال ها مکانیسم جدا getChannelDifference هست، چون هر کانال pts مستقل داره و این باعث میشه شما فقط کانال هایی رو بگیری که تغییر کردن! برای سوپر گروه هم مکانیزم همینه.

این باعث می‌شه حتی اگر چند ساعت آفلاین باشی، بعد از اتصال دوباره دقیقاً همه‌چی رو بگیری و هیچ پیامی رو از دست ندی

حتی با packet loss یا reconnect، state کلاینت خراب نمیشه و سرور مجبور نیست برای هر کلاینت همه چی رو دوباره بفرسته. فقط gap ها sync میشن

<Abolfazl/>

🔵 عنوان مقاله
Cypress — How to Create Automatic Weekly Flake Alerting

🟢 خلاصه مقاله:
این مقاله نشان می‌دهد چگونه برای تست‌های flaky در Cypress یک سیستم هشدار هفتگی خودکار بسازیم. ابتدا با جمع‌آوری خروجی‌های قابل‌ماشین از CI (مثل JUnit/JSON) و ذخیره‌سازی نتایج هر اجرا، داده‌های لازم گردآوری می‌شود. سپس با محاسبه نرخ فلاکی در سطح تست و فایل، مقایسه هفتگی و شناسایی «پرتکرارترین» موارد، مهم‌ترین منابع ناپایداری مشخص می‌گردد. در ادامه، یک کار زمان‌بندی‌شده هفتگی گزارش خلاصه را به Slack یا ایمیل ارسال می‌کند و لینک‌هایی برای بررسی تاریخچه و اجرای‌های مشکل‌دار ارائه می‌دهد. در نهایت، با یک فرآیند تیمی ساده—تریاژ هفتگی، ایجاد تیکت، قرنطینه موقت تست‌های بد و تعیین آستانه/SLO—می‌توان نویز را کاهش داد، پایداری CI را افزایش داد و اعتماد توسعه‌دهندگان را بهبود بخشید.

🟣لینک مقاله:
https://cur.at/ChOQXrI?m=web

➖➖➖➖➖➖➖➖
👑 @software_Labdon

ارتباط IPv6 از سمت زیرساخت کشور دچار اختلال و قطعی شده است.

🔵 عنوان مقاله
Testing AI: 5 obstacles and 7 workarounds

🟢 خلاصه مقاله:
این گفت‌وگو یک ساعتۀ نیکیتا سیدروویچ با مایکل بولتن به چالش‌های آزمون‌پذیری هوش مصنوعی می‌پردازد. پنج مانع اصلی شامل مسئلۀ اوراکل (نامشخص بودن پاسخ درست), غیرقطعی بودن خروجی‌ها, ابهام‌پذیری مدل, مشکلات کیفیت و偏‌داری داده, و فرسایش/دریفت در گذر زمان مطرح می‌شود. در برابر آن، هفت راهکار عملی پیشنهاد می‌شود: تعریف چند اوراکل و بازه‌های پذیرش، اتکا به سنجه‌های آماری و مقایسه با مبنا، ساخت داده‌های آزمون متنوع و سناریومحور (از جمله مصنوعی و خصمانه)، ارتقای مشاهده‌پذیری و ارزیابی پس از استقرار، آزمون اکتشافی و مبتنی بر ریسک با مشارکت ذی‌نفعان، افزودن ریل‌های ایمنی و انسان در حلقه برای تصمیم‌های حساس، و ارزیابی/نسخه‌بندی مداوم با حلقه‌های بازخورد. جمع‌بندی گفتگو بر تغییر نگرش تأکید دارد: آزمون هوش مصنوعی بیش از اثبات درستی، درباره توصیف رفتار، مدیریت ریسک و تصمیم‌سازی آگاهانه است.

🟣لینک مقاله:
https://cur.at/LHGWGqf?m=web

➖➖➖➖➖➖➖➖
👑 @software_Labdon

امروز یکی از همکارانم سوال خوبی پرسید که فکر می‌کنم دغدغه خیلی‌هاست:
"فرق واقعی Async و Concurrency چیه؟ مگه هر دو به معنی انجام همزمان کارها نیستن؟"
این دو مفهوم اغلب با هم اشتباه گرفته می‌شن. بذارید با یک مثال ساده تفاوتشون رو باز کنم:
۱. Synchronous vs. Asynchronous
این مفاهیم درباره انتظار کشیدن هستن.
Sync
مثل اینه که بری کافه، قهوه سفارش بدی و همونجا جلوی پیشخوان منتظر بمونی تا آماده بشه و تحویل بگیری.
تا قهوه رو نگیری، هیچ کار دیگه‌ای نمی‌کنی.
Async
سفارش می‌دی، یک پیجر (Pager) می‌گیری و می‌ری سر میزت می‌نشینی.
در این فاصله می‌تونی ایمیل‌هاتو چک کنی.
هر وقت قهوه‌ات آماده شد، پیجر بهت خبر می‌ده.
تو منتظر نموندی و از زمانت استفاده کردی.

۲. Concurrency
این مفهوم درباره مدیریت چند کار در یک بازه زمانی هست.
باریستای کافه رو در نظر بگیرید:
اون همزمان هم سفارش شما رو آماده می‌کنه، هم سفارش نفر بعدی رو می‌گیره و هم شیر رو برای یک سفارش دیگه گرم می‌کنه.
در واقع اون با جابجایی سریع بین کارها (Context Switching)، چند وظیفه رو پیش می‌بره.
این یعنی هم‌روندی.

نکته کلیدی
برنامه‌نویسی Async یکی از راه‌های رسیدن به Concurrency هست.
درک این تفاوت، در طراحی سیستم‌های مدرن مثل میکروسرویس‌ها یا پایپ‌لاین‌های پردازش دیتا، یک مزیت فوق‌العاده است.
این درک به شما کمک می‌کنه تا بین ابزارهایی مثل Kafka, gRPC یا WebSockets انتخاب درستی داشته باشید و سیستمی بسازید که هم Scalable و هم Reliable باشه.


@ | <Ali Naseri/>