Software Engineer Labdon
608 subscribers
43 photos
4 videos
2 files
760 links
👑 Software Labdon

حمایت مالی:
https://www.coffeete.ir/mrbardia72

ادمین:
@mrbardia72
Download Telegram
🔵 عنوان مقاله
Sauron (GitHub Repo)

🟢 خلاصه مقاله:
ساز ابزار Sauron در GitHub Repo یک ابزار متن‌باز برای دیدن «دسترسی واقعی» یک Credential به‌دست‌آمده در محیط‌های Active Directory است. این ابزار با جمع‌آوری و هم‌بست‌ کردن عضویت‌ها (حتی عضویت‌های تو در تو)، مجوزها و زمینه‌های مرتبط، تصویر شفافی از دسترسی مؤثر و «محدوده اثر» آن Credential ارائه می‌دهد. خروجی‌های ساخت‌یافته، مجوزهای بیش‌ازحد، تفویض‌های پرریسک و عضویت‌های گسترده را برجسته می‌کنند و برای تیم‌های Blue/Red و تیم‌های Incident Response در ارزیابی ریسک، مهار سریع و اعتبارسنجی اصل حداقل دسترسی مفید است. Sauron فقط بر پرس‌وجوی خواندنی تکیه دارد، بهره‌برداری انجام نمی‌دهد و به‌صورت شفاف و قابل توسعه در GitHub Repo در دسترس است؛ استفاده از آن صرفاً در چارچوب مجاز و قانونی توصیه می‌شود.

#ActiveDirectory #CyberSecurity #IncidentResponse #BlueTeam #RedTeam #IdentitySecurity #WindowsSecurity #Sauron

🟣لینک مقاله:
https://github.com/sikumy/sauron?utm_source=tldrinfosec


👑 @software_Labdon
🔵 عنوان مقاله
Make Selenium Test Smarter with AI — Local/Cloud LLMs

🟢 خلاصه مقاله:
این ویدئوی کوتاه از Karthik K.K. نشان می‌دهد چگونه می‌توان با ترکیب Selenium و AI (به‌ویژه LLMs)، فرایند تست خودکار را هوشمندتر کرد. تمرکز بر قابلیت‌هایی مانند تولید خودکار اسکریپت از توضیحات طبیعی، self-healing برای locatorها، ساخت assertionهای معنادار، و تحلیل خطاها و لاگ‌ها برای ریشه‌یابی سریع‌تر است. همچنین به مزایا و معایب LLMهای Local در برابر Cloud پرداخته می‌شود: حفظ داده و هزینه قابل پیش‌بینی در Local در مقابل کیفیت، مقیاس‌پذیری و سهولت اتصال در Cloud. در نهایت، رویکردی گام‌به‌گام برای شروع پیشنهاد می‌شود تا تیم‌ها بدون جایگزین‌کردن مهارت مهندس تست، با افزودن AI به Selenium، سرعت تولید تست، پایداری و کیفیت بازخورد را بهبود دهند.

#Selenium #AI #LLM #TestAutomation #SoftwareTesting #QA #DevTools #CI_CD

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


👑 @software_Labdon
🔵 عنوان مقاله
Beyond the Test Pyramid: Building New Monuments for Testing

🟢 خلاصه مقاله:
خوانش تازه‌ای از مدل کلاسیک test pyramid ارائه می‌شود: Juan Rada می‌گوید تکیه افراطی بر لایه‌های پایین (مثل unit tests) همیشه به‌صرفه نیست، چون در سیستم‌های توزیع‌شده نیاز به mocking زیاد، شکنندگی و هزینه نگه‌داری بالا ایجاد می‌کند و اعتماد کاذب می‌دهد. او پیشنهاد می‌کند به‌جای قالب ثابت، پرتفوی آزمون بر اساس ریسک و زمینه تیم چیده شود: تمرکز بیشتر بر integration tests معنادار، چند E2E هدفمند و سریع، و contract testing برای محافظت از مرز سرویس‌ها. این رویکرد با observability، tracing، health checks، و به‌کارگیری feature flags و canary releases برای اعتبارسنجی امن در محیط واقعی تکمیل می‌شود. هدف کنار گذاشتن unit tests نیست، بلکه اندازه‌کردن درست آن‌ها و ساختن «monuments» متناسب با معماری و اهداف است تا تعادل بهینه‌ای میان هزینه، سرعت و ریسک ایجاد شود.

#Testing #TestPyramid #SoftwareQuality #RiskBasedTesting #IntegrationTesting #E2E #QualityEngineering

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


👑 @software_Labdon
Forwarded from Gopher Academy
واسه برنامه نویسی سیستمی کدوم رو ترجیح میدید؟
البته: با توضیح زیر در نظر بگیرید و انتخاب کنید
اگر می‌خوای کاملاً به سخت‌افزار نزدیک باشی → برو سراغ C. اگر می‌خوای ساختار بهتر + سرعت بالا داشته باشی → C++. اگر برات ایمنی و مدرن بودن مهمه → Rust.
Anonymous Poll
36%
C
35%
C++
53%
Rust
🔵 عنوان مقاله
Mutation testing — not just for unit tests

🟢 خلاصه مقاله:
mutation testing روشی برای سنجش کیفیت واقعی آزمون‌هاست: با ایجاد تغییرات کوچک در کد، بررسی می‌کند آیا تست‌ها می‌توانند خطاهای احتمالی را کشف کنند یا نه. این رویکرد فقط مخصوص unit tests نیست؛ می‌توان آن را در سطح integration و API و حتی سناریوهای انتها به انتها به‌کار گرفت تا مطمئن شویم تست‌ها رفتار قابل مشاهده را به‌خوبی پوشش می‌دهند. Bas Dijkstra با یک مثال گام‌به‌گام نشان می‌دهد چگونه ابزار را پیکربندی کنیم، mutants بسازیم، تست‌ها را اجرا کنیم و نتایج را تفسیر کنیم؛ و چگونه با تقویت assertions، افزودن سناریوهای لبه، یا حذف کد مرده کیفیت را بالا ببریم. پیشنهاد عملی این است که با یک بخش کوچک شروع کنید، ابزار مناسب پشته‌تان را انتخاب کنید، در CI آستانه‌های معقول بگذارید و اجرای سنگین‌تر را دوره‌ای انجام دهید تا با هزینه منطقی، بازخورد مؤثر بگیرید.

#MutationTesting #SoftwareTesting #UnitTesting #TestQuality #BasDijkstra #CodeCoverage #CI_CD #DevOps

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


👑 @software_Labdon
🎉1
🔵 عنوان مقاله
Authorization vulnerabilities in public APIs are shockingly common (Sponsor)

🟢 خلاصه مقاله:
**این مطلبِ اسپانسری نشان می‌دهد آسیب‌پذیری‌های مجوزدهی در public APIs بسیار شایع‌اند. Intruder با استفاده از ابزار Autoswagger روی اهدافی از چند برنامه بزرگ bug bounty اسکن انجام داد و مواردی از افشای اعتبارنامه‌ها را در APIs متعلق به Microsoft و دیگر شرکت‌های بزرگ یافت. این نمونه‌ها بیانگر مشکلات سیستماتیک در کنترل دسترسی و تنظیم نادرست سطح دسترسی هستند. در مقاله نمونه‌های واقعی ارائه شده و امکان دریافت رایگان Autoswagger برای آزمون در محیط‌های خودتان فراهم است.

#API #APISecurity #Authorization #Intruder #Autoswagger #BugBounty #Microsoft #CyberSecurity

🟣لینک مقاله:
https://www.intruder.io/research/broken-authorization-apis-autoswagger?utm_source=tldrinfosec&utm_medium=p_referral&utm_campaign=global%7Cfixed%7Cautoswagger_26_08_25


👑 @software_Labdon
😈1
👋 درود به همه دوستان عزیز

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

🤝 اینطوری هم به بقیه کمک می‌کنید و هم محتوای ارزشمندتون بیشتر دیده میشه.
@mrbardia72
An alternative to Scrum: no endless backlogs, fixed 6-week cycles, and more autonomy for teams. Focus on shaping, betting, and shipping real work.
یه متدلوژی جایگزین برای Scrum که خیلی جدیدا مد شده. یه سری فرق‌های جالب داره و توی این کتاب خلاصه شده خودشون توضیح دادن که دقیقا چیه و کی میشه ازش استفاده کرد.

#Agile #Scrum #Methodology #Software #Practice


https://basecamp.com/shapeup/shape-up.pdf
1
🔵 عنوان مقاله
Debugging "No Tests Found" Errors in Playwright: A Comprehensive Guide

🟢 خلاصه مقاله:
راهنمای Marius Besel نشان می‌دهد که خطای “No Tests Found” در Playwright معمولاً به دلیل کشف‌نشدن فایل‌های تست یا حذف‌شدن آن‌ها توسط الگوها و فیلترها رخ می‌دهد. او تأکید می‌کند ابتدا نام‌گذاری و محل فایل‌ها را بررسی کنید: Playwright به‌طور پیش‌فرض در testDir (مثلاً tests) به‌دنبال *.spec.* یا *.test.* می‌گردد و هر تغییری در testMatch/testIgnore یا اجرای دستور در مسیر اشتباه می‌تواند کشف را از کار بیندازد. سپس فیلترها و پروژه‌ها را چک کنید: پارامترهایی مثل --grep، --grep-invert، --project یا دادن مسیری که تستی در آن نیست، ممکن است همه چیز را حذف کند؛ استفاده از --list کمک می‌کند بفهمید دقیقاً چه تست‌هایی شناسایی می‌شوند. در ساختارهای monorepo، چندین فایل playwright.config و اسکریپت‌های workspace می‌توانند Playwright را به دایرکتوری‌های نادرست ببرند.

برای TypeScript، مشکلات outDir، تفاوت ESM/CJS، و تنظیمات include/exclude در tsconfig می‌تواند مانع کشف تست‌ها شود؛ هم‌تراز کردن testDir با tsconfig، پرهیز از تزاحم فرایندهای جداگانه ترنسپایل، و یکنواخت‌کردن تنظیمات ماژول معمولاً مشکل را حل می‌کند. تفاوت محیط‌ها نیز مهم است: حساسیت به حروف در Linux، مسیرها و متغیرهای محیطی در CI، و ناهمخوانی نسخه‌ها می‌توانند باعث بروز خطا شوند. جمع‌بندی او یک چک‌لیست عملی است: نام‌گذاری/محل فایل‌ها، تنظیمات testDir/testMatch/testIgnore، فیلترها و پروژه‌ها، تنظیمات TypeScript/ماژول، و یکسان‌سازی محیط محلی و CI—با این مراحل، پیام “No Tests Found” به‌سادگی برطرف می‌شود.

#Playwright #Testing #Debugging #JavaScript #TypeScript #E2E #CI #TestAutomation

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


👑 @software_Labdon
🔵 عنوان مقاله
Why Secure Document Editing is More Important than Ever (3 minute read)

🟢 خلاصه مقاله:
**سازمان‌ها به‌دلیل گسترش همکاری ابری و کار ترکیبی، در همه مراحل چرخه اسناد هدف حملات قرار می‌گیرند؛ از پیش‌نویس تا اشتراک‌گذاری. ابزارهای سنتی اغلب فاقد رمزنگاری انتها‌به‌انتها، کنترل دسترسی دقیق، ثبت رویداد قابل اتکا و DLP هستند و همین شکاف‌ها می‌تواند به نشت داده، آسیب اعتباری و جریمه‌های مقرراتی (مانند GDPR، CCPA و HIPAA) منجر شود. راهکارهای امنِ ویرایش سند با رمزنگاری قوی، SSO و MFA، حداقل‌سازی دسترسی، سیاست‌های اشتراک‌گذاری، حقوق محتوا، رد‌سازی، لاگ‌های غیرقابل‌دستکاری و پشتیبانی از استانداردهایی مانند SOC 2 و ISO 27001، هم‌زمان امنیت، یکپارچگی داده و انطباق را تضمین می‌کنند و با DLP، CASB و SIEM یکپارچه می‌شوند. اقدام‌های پیشنهادی شامل نقشه‌برداری ریسک اسناد، انتخاب پلتفرم دارای ارزیابی مستقل، فعال‌سازی MFA و دسترسی حداقلی، لینک‌های منقضی‌شونده و نشانه‌گذاری، آموزش مستمر و پایش مبتنی بر تلمتری است. ویرایش امن اسناد امروز یک الزام راهبردی است که امنیت را به نزدیک‌ترین نقطه به داده می‌آورد و انطباق را در مقیاس ممکن می‌کند.

#Cybersecurity #DocumentSecurity #DataProtection #Encryption #Compliance #SecureCollaboration #ZeroTrust #DLP

🟣لینک مقاله:
https://hackread.com/why-secure-document-editing-important-than-ever/?utm_source=tldrinfosec


👑 @software_Labdon
🔵 عنوان مقاله
Leveraging Copilot to rapidly refactor test automation

🟢 خلاصه مقاله:
خلاصه‌ای از دیدگاه Maxwell Nyamunda: با تکیه بر GitHub Copilot می‌توان بازآرایی (Refactor) تست‌های خودکار را سریع‌تر و ایمن‌تر انجام داد. Copilot در حذف تکرار، استانداردسازی نام‌گذاری، تبدیل تست‌ها به قالب Arrange‑Act‑Assert، جایگزینی sleep با explicit wait، بهبود assertها و پارامتری‌سازی تست‌ها کمک می‌کند. برای مهاجرت‌های بزرگ‌تر—مثلاً از Selenium + TestNG به Playwright، Cypress یا Jest—می‌تواند نگهدارنده‌ها و locatorها را ترجمه کند، Page Object Model را بازسازی یا الگوی Screenplay را پیشنهاد دهد، و با mock/stub و fixtureها داده‌ی تست را سامان دهد. همچنین در تولید نام‌های توصیفی تست، سناریوهای BDD/Gherkin، پیام‌های commit و توضیحات PR و چک‌لیست‌های CI مفید است. کلید موفقیت، دادن زمینه و قیود روشن در promptها، درخواست تغییرات کوچک و قابل بازبینی، و راستی‌آزمایی مداوم در لوکال و CI است—همراه با رعایت حریم خصوصی و مرور انسانی برای تصمیم‌های حساس.

#GitHubCopilot #TestAutomation #Refactoring #QA #SDET #Playwright #Cypress

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


👑 @software_Labdon
بچه هایی که میخوایید از تست XSS خیالتون راحت باشه تا روی بقیه آسیب پذیری ها متمرکز بشید حتما از Reflix استفاده کنید حتما هم با سوییچ -he اجرا کنید تا تستون کامل بشه ،

Github
github.com/nexovir/reflix
ReCommand :

reflix -l urls -X GET  -c 15 --dom --headless --xss -pi -hi -he

<sardine web/>
1🤝1
🔵 عنوان مقاله
Ruby Central's Attack on RubyGems (2 minute read)

🟢 خلاصه مقاله:
Ellen Dash (duckinator)، یکی از نگهدارندگان اصلی RubyGems، پس از آنکه Ruby Central کنترل سازمان GitHub مربوط به RubyGems را به‌صورت خصمانه در دست گرفت، از Ruby Central استعفا داد. در ۹ سپتامبر، یکی از نگهدارندگان RubyGems، Marty Haught از Ruby Central را به GitHub enterprise پروژه افزود، نام آن را به “Ruby Central” تغییر داد و سایر نگهدارندگان را حذف کرد؛ سپس آن‌ها را بازگرداند، اما مالکیت سازمان در اختیار Marty Haught باقی ماند. بعدها در همان ماه، برخی نگهدارندگان دوباره حذف شدند. این رویداد نگرانی‌های جدی درباره حاکمیت پروژه، شفافیت، نمایندگی جامعه و امنیت زنجیره تأمین در اکوسیستم Ruby برانگیخت و درخواست‌ها برای فرآیندهای شفاف و کنترل دسترسی روشن‌تر را افزایش داد.

#RubyGems #RubyCentral #Ruby #GitHub #OpenSource #Governance #Maintainers #SupplyChainSecurity

🟣لینک مقاله:
https://pup-e.com/goodbye-rubygems.pdf?utm_source=tldrinfosec


👑 @software_Labdon
1
🔵 عنوان مقاله
PyPI urges users to reset credentials after new phishing attacks (2 minute read)

🟢 خلاصه مقاله:
کاربران PyPI هدف حملات فیشینگ تازه‌ای قرار گرفته‌اند که به‌کمک دامنه‌های جعلی مانند pypi-mirror.org و پیش‌تر pypj.org خود را به‌جای PyPI جا می‌زنند. ایمیل‌ها با ادعای "account maintenance and security procedures" قربانی را به صفحه‌های ورود تقلبی هدایت می‌کنند تا اطلاعات ورود را سرقت کنند. مهاجمان سپس با این اطلاعات حساب‌های توسعه‌دهندگان را تصاحب کرده و با آلوده‌کردن نسخه‌های منتشرشده یا انتشار پکیج‌های جدید مخرب در PyPI، زنجیره تأمین نرم‌افزار را تهدید می‌کنند. Python Software Foundation توصیه کرده است رمزعبور و سایر اعتبارات (از جمله API tokens) را فوراً بازنشانی/گردش دهید، 2FA را فعال کنید، توکن‌های مشکوک را لغو کرده و تاریخچه انتشار پکیج‌ها را بررسی کنید. همچنین قبل از واردکردن اطلاعات، حتماً دامنه واقعی pypi.org را تأیید کرده و نسبت به ایمیل‌های ناخواسته با مضامین امنیت و نگهداری حساب محتاط باشید و موارد مشکوک را گزارش دهید.

#PyPI #Python #Phishing #Cybersecurity #OpenSourceSecurity #SoftwareSupplyChain #PSF #Infosec

🟣لینک مقاله:
https://www.bleepingcomputer.com/news/security/pypi-urges-users-to-reset-credentials-after-new-phishing-attacks/?utm_source=tldrinfosec


👑 @software_Labdon
1
🔵 عنوان مقاله
Vietnamese Hackers Use Fake Copyright Notices to Spread Lone None Stealer (1 minute read)

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

#Cybersecurity #Phishing #Malware #SocialEngineering #Infosec #LoneNone #DMCA

🟣لینک مقاله:
https://hackread.com/vietnamese-hackers-fake-copyright-notice-lone-none-stealer/?utm_source=tldrinfosec


👑 @software_Labdon
🔵 عنوان مقاله
Spring Boot Testing: From Unit to End-to-End Testing

🟢 خلاصه مقاله:
این مطلب با مرور رویکردی عملی برای تست خودکار در Spring Boot از تست واحد تا تست انتها‌به‌انتها، بر «هرم تست» و انتخاب سبک‌ترین سطحی که اعتماد کافی می‌دهد تأکید می‌کند. برای تست‌های واحد، از JUnit 5، AssertJ و Mockito استفاده کنید و تا حد امکان از بارگذاری Spring Context پرهیز کنید. در سطح میانی، «test slice»‌ها مانند @WebMvcTest با MockMvc و @DataJpaTest (همراه با پایگاه‌داده درون‌حافظه یا Testcontainers) لایه‌ها را هدفمند و سریع پوشش می‌دهند. برای یکپارچه‌سازی گسترده‌تر، @SpringBootTest به‌همراه Testcontainers (برای PostgreSQL/Kafka/RabbitMQ) و اعمال مهاجرت‌ها با Flyway/Liquibase توصیه می‌شود؛ وابستگی‌های بیرونی را با WireMock یا تست‌های قرارداد پایدار کنید. در رأس هرم، تعداد کمی تست E2E اما معنادار (اغلب در سطح API با RestAssured) کافی است؛ ترتیب اجرای CI از سریع به کند، پروفایل‌های تست، داده‌های تست قابل تکرار و مراقبت از شکنندگی، کیفیت و سرعت بازخورد را تضمین می‌کند. نویسنده: Philip Riecks.

#SpringBoot #SoftwareTesting #JUnit5 #Testcontainers #Mockito #WireMock #Java

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


👑 @software_Labdon
Forwarded from Bardia & Erfan
اگه با دلار ۱۰۰۰ تومنی زندگیتو جمع کردی
با دلار ۱۰۰ تومنی نصیحت نکن.
🔵 عنوان مقاله
DiffRays (GitHub Repo)

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

#BinaryDiffing #ReverseEngineering #VulnerabilityResearch #ExploitDevelopment #PatchAnalysis #SecurityTools #MalwareAnalysis #SoftwareSecurity

🟣لینک مقاله:
https://github.com/pwnfuzz/diffrays?utm_source=tldrinfosec


👑 @software_Labdon
👌1
🔵 عنوان مقاله
WOW. Playwright is significantly better than Selenium

🟢 خلاصه مقاله:
این روزها بسیاری از تسترها می‌گویند Playwright نسبت به Selenium برتری چشمگیری دارد و بحث‌های Reddit نیز با تجربه‌های واقعیِ مهاجرت این موضوع را تأیید می‌کند. مهم‌ترین مزیت‌ها: کاهش چشمگیر فلِیکی به‌خاطر auto-waiting و زمان‌بندی هوشمند، API مدرن و سازگار در مرورگرهای مختلف، و ابزارهای یکپارچه مثل test runner، اجرای موازی، tracing، و ضبط ویدئو/اسکرین‌شات که دیباگ را ساده و چرخه بازخورد در CI/CD را کوتاه می‌کنند. بسیاری گزارش داده‌اند که با Playwright کد کمتر، پایداری بیشتر و پوشش cross-browser روان‌تری دارند. با این حال، در کنار این مزایا به بلوغ و اکوسیستم گسترده Selenium هم اشاره می‌شود؛ انتخاب نهایی به نیازها و زمینه پروژه وابسته است، اما برای تیم‌هایی که سرعت، پایداری و تجربه توسعه‌دهنده را در اولویت می‌گذارند، Playwright گزینه برتر جلوه می‌کند.

#Playwright #Selenium #TestAutomation #WebTesting #QA #E2E #CI_CD #Reddit

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


👑 @software_Labdon
در نگاه اول async کردن یه روند بیزینسی یا فنی شاید ساده به نظر بیاد و خیلی مزیت ها داشته باشه. معماری هایی مثل event-driven هم خیلی معروف هستند و پرطرفدار
اما در واقعیت و روی مقیاس بالا چالش های مهمی هم دارند که باید بهشون توجه بشه
چالش هایی مثل observability و idempotency و حتی درک موضوع eventual consistency خودش میتونه چالش برانگیز باشه
این مقاله کوتاه نکات خوبی رو اشاره کرده در این مورد
Why are Event-Driven Systems Hard?
Understanding the Core Challenges of Asynchronous Architectures
https://newsletter.scalablethread.com/p/why-event-driven-systems-are-hard
Forwarded from VIP
🚀 به دنیای توسعه و تکنولوژی خوش اومدی!

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

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

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

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

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