هشدار به کاربران رم‌های DDR5: در کمتر از ۲ دقیقه هک می‌شوید!
«آسیب‌پذیری سخت‌افزاری» نوعی مشکل در ذات قطعات الکترونیکی است و برخلاف مشکلات نرم‌افزاری، اصلاح‌اش بسیار سخت‌تر است.
حالا محققان دانشگاه ETH زوریخ و گوگل از یک «آسیب‌پذیری سخت‌افزاری» پرده برداشته‌اند که در قلب حافظه‌های رم (RAM) کمین کرده. این رخنه امنیتی که «ققنوس» نام گرفته نسل جدید حافظه‌های DDR5 و به‌ویژه تراشه‌های ساخت شرکت مشهور SK Hynix را هدف می‌گیرد.
آسیب‌پذیری ققنوس چیست؟
ققنوس مدل جدیدی از آسیب‌پذیری RowHammer است که از چند سال قبل شناخته شده بود. این آسیب‌پذیری به زبان ساده مثل ضربه زدن پیاپی به قفسه کتاب‌ها است. اگر به یک ردیف بیش از حد کوبیده شود، قفسه کناری هم تکان می‌خورد و کتاب‌های آن از جایش می‌افتند.
در چیپ‌های حافظه همین اتفاق رخ می‌دهد؛ با دستکاری مکرر یک ردیف، داده‌های ردیف‌های کناری دچار «بیت فلاپ» شده و بین صفر و یک جابجا می‌شوند. این تغییرات کوچک در ظاهر بی‌اهمیت‌اند، اما مهاجمان با همین روش به سیستم دسترسی غیرمجاز پیدا می‌کنند.
در ایران حافظه‌های RAM برند SK به دلیل قیمت مناسب سهم قابل توجهی از بازار را در اختیار دارند. همین باعث می‌شود بخشی از کاربران خانگی و حتی کسب‌وکارها ناخواسته در معرض ریسک قرار گیرند.
ققنوس از خاکستر برمی‌خیزد
سازندگان حافظه از این آسیب‌پذیری آگاه بودند و برای مقابله با آن سپرهای دفاعی مختلفی را طراحی کردند. اما حمله ققنوس نشان داد که این سپرها دیگر کافی نیستند.
ابزارهایی که قرار بود جلوی این نقص را بگیرند (مانند تصحیح خطای ECC) در برابر حمله‌ی ققنوس کارایی ندارند.
روش جدید به‌حدی خطرناک است که همه ۱۵ تراشه DDR5 آزمایش‌شده (تولید سال‌های ۲۰۲۱ تا ۲۰۲۴) در برابر آن تسلیم شدند. هکرها با استفاده از این تکنیک می‌توانند:
• کلید اصلی را بدزدند: با تغییر دادن چند صفر و یک در جای درست، مهاجم به سیستم می‌قبولاند که مدیر اصلی (روت) است و کنترل کامل کامپیوتر را در دست بگیرد.
• قفل‌های امنیتی را بشکنند: این حمله می‌تواند کلیدهای رمزنگاری را تخریب کرده و به اطلاعات حساس مانند رمزهای عبور دسترسی پیدا کند.
ترسناک‌تر اینکه تمام این فرآیند در کمتر از دو دقیقه (حدود ۱۰۹ ثانیه) روی یک سیستم استاندارد و به‌روز قابل اجراست.
راه چاره چیست؟
مشکل اینجاست که ققنوس یک ضعف سخت‌افزاری است، نه نرم‌افزاری. بنابراین نمی‌شود آن را با یک آپدیت ساده یا نصب وصله امنیتی برطرف کرد. تراشه‌هایی که بین سال‌های ۲۰۲۱ تا ۲۰۲۴ تولید شده‌اند، این ضعف را در ذات خود دارند و برای سال‌ها آسیب‌پذیر باقی خواهند ماند.
محققان توصیه کرده‌اند که نرخ بازخوانی (Refresh Rate) حافظه تا سه برابر افزایش یابد تا این روش خنثی شود، اما همین هم راهکاری موقت و تخصصی است.
<NooshDaroo/>
«آسیب‌پذیری سخت‌افزاری» نوعی مشکل در ذات قطعات الکترونیکی است و برخلاف مشکلات نرم‌افزاری، اصلاح‌اش بسیار سخت‌تر است.
حالا محققان دانشگاه ETH زوریخ و گوگل از یک «آسیب‌پذیری سخت‌افزاری» پرده برداشته‌اند که در قلب حافظه‌های رم (RAM) کمین کرده. این رخنه امنیتی که «ققنوس» نام گرفته نسل جدید حافظه‌های DDR5 و به‌ویژه تراشه‌های ساخت شرکت مشهور SK Hynix را هدف می‌گیرد.
آسیب‌پذیری ققنوس چیست؟
ققنوس مدل جدیدی از آسیب‌پذیری RowHammer است که از چند سال قبل شناخته شده بود. این آسیب‌پذیری به زبان ساده مثل ضربه زدن پیاپی به قفسه کتاب‌ها است. اگر به یک ردیف بیش از حد کوبیده شود، قفسه کناری هم تکان می‌خورد و کتاب‌های آن از جایش می‌افتند.
در چیپ‌های حافظه همین اتفاق رخ می‌دهد؛ با دستکاری مکرر یک ردیف، داده‌های ردیف‌های کناری دچار «بیت فلاپ» شده و بین صفر و یک جابجا می‌شوند. این تغییرات کوچک در ظاهر بی‌اهمیت‌اند، اما مهاجمان با همین روش به سیستم دسترسی غیرمجاز پیدا می‌کنند.
در ایران حافظه‌های RAM برند SK به دلیل قیمت مناسب سهم قابل توجهی از بازار را در اختیار دارند. همین باعث می‌شود بخشی از کاربران خانگی و حتی کسب‌وکارها ناخواسته در معرض ریسک قرار گیرند.
ققنوس از خاکستر برمی‌خیزد
سازندگان حافظه از این آسیب‌پذیری آگاه بودند و برای مقابله با آن سپرهای دفاعی مختلفی را طراحی کردند. اما حمله ققنوس نشان داد که این سپرها دیگر کافی نیستند.
ابزارهایی که قرار بود جلوی این نقص را بگیرند (مانند تصحیح خطای ECC) در برابر حمله‌ی ققنوس کارایی ندارند.
روش جدید به‌حدی خطرناک است که همه ۱۵ تراشه DDR5 آزمایش‌شده (تولید سال‌های ۲۰۲۱ تا ۲۰۲۴) در برابر آن تسلیم شدند. هکرها با استفاده از این تکنیک می‌توانند:
• کلید اصلی را بدزدند: با تغییر دادن چند صفر و یک در جای درست، مهاجم به سیستم می‌قبولاند که مدیر اصلی (روت) است و کنترل کامل کامپیوتر را در دست بگیرد.
• قفل‌های امنیتی را بشکنند: این حمله می‌تواند کلیدهای رمزنگاری را تخریب کرده و به اطلاعات حساس مانند رمزهای عبور دسترسی پیدا کند.
ترسناک‌تر اینکه تمام این فرآیند در کمتر از دو دقیقه (حدود ۱۰۹ ثانیه) روی یک سیستم استاندارد و به‌روز قابل اجراست.
راه چاره چیست؟
مشکل اینجاست که ققنوس یک ضعف سخت‌افزاری است، نه نرم‌افزاری. بنابراین نمی‌شود آن را با یک آپدیت ساده یا نصب وصله امنیتی برطرف کرد. تراشه‌هایی که بین سال‌های ۲۰۲۱ تا ۲۰۲۴ تولید شده‌اند، این ضعف را در ذات خود دارند و برای سال‌ها آسیب‌پذیر باقی خواهند ماند.
محققان توصیه کرده‌اند که نرخ بازخوانی (Refresh Rate) حافظه تا سه برابر افزایش یابد تا این روش خنثی شود، اما همین هم راهکاری موقت و تخصصی است.
<NooshDaroo/>
❤2
🔵 عنوان مقاله
What I learned extending zero trust to the storage layer (7 minute read)
🟢 خلاصه مقاله:
سازمان‌ها معمولاً zero trust را برای کاربر، برنامه و شبکه اجرا می‌کنند اما لایه ذخیره‌سازی را نادیده می‌گیرند؛ جایی که پشتیبان‌ها، اسنپ‌شات‌ها و فراداده بازیابی نگهداری می‌شود و هدف اول باج‌افزارهای مدرن است. نمونه‌های پر سر و صدا، از جمله Change Healthcare، نشان می‌دهند وقتی مهاجم به صفحه مدیریت ذخیره‌سازی و بکاپ برسد، نقاط بازیابی هم از بین می‌روند و تداوم کسب‌وکار به‌سرعت مختل می‌شود. نویسنده سه اصل کلیدی را مطرح می‌کند: ۱) کنترل سخت‌گیرانه دسترسی شبکه به APIهای ذخیره‌سازی با جداسازی صفحه مدیریت/داده، احراز هویت قوی، فهرست‌های مجاز و پایش مداوم؛ ۲) هویت «در لحظه» با حداقل اختیار و تفکیک وظایف، حذف حساب‌های مشترک، MFA و تأیید عملیات مخرب (مثل حذف اسنپ‌شات یا تغییر نگهداشت)؛ ۳) مصون‌سازی داده‌های بازیابی با WORM/immutability، قفل‌های نگهداشت و یک خزانه بازیابی ایزوله که کلیدها و سیاست‌هایش خارج از دامنه اصلی کنترل شود. برای عملیاتی‌سازی نیز باید سیاست‌ها را کدنویسی، ممیزی و به‌طور منظم سناریوهای حذف بکاپ/کاهش نگهداشت را تمرین و بازیابی از نسخه‌های غیرقابل‌تغییر را تست کرد. نتیجه: تعمیم zero trust به ذخیره‌سازی، آخرین خط دفاع—یعنی بکاپ—را واقعاً مقاوم می‌کند.
#ZeroTrust #Ransomware #StorageSecurity #APIProtection #WORM #BackupImmutability #IdentitySecurity
🟣لینک مقاله:
https://www.csoonline.com/article/4061829/what-i-learned-extending-zero-trust-to-the-storage-layer.html?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
What I learned extending zero trust to the storage layer (7 minute read)
🟢 خلاصه مقاله:
سازمان‌ها معمولاً zero trust را برای کاربر، برنامه و شبکه اجرا می‌کنند اما لایه ذخیره‌سازی را نادیده می‌گیرند؛ جایی که پشتیبان‌ها، اسنپ‌شات‌ها و فراداده بازیابی نگهداری می‌شود و هدف اول باج‌افزارهای مدرن است. نمونه‌های پر سر و صدا، از جمله Change Healthcare، نشان می‌دهند وقتی مهاجم به صفحه مدیریت ذخیره‌سازی و بکاپ برسد، نقاط بازیابی هم از بین می‌روند و تداوم کسب‌وکار به‌سرعت مختل می‌شود. نویسنده سه اصل کلیدی را مطرح می‌کند: ۱) کنترل سخت‌گیرانه دسترسی شبکه به APIهای ذخیره‌سازی با جداسازی صفحه مدیریت/داده، احراز هویت قوی، فهرست‌های مجاز و پایش مداوم؛ ۲) هویت «در لحظه» با حداقل اختیار و تفکیک وظایف، حذف حساب‌های مشترک، MFA و تأیید عملیات مخرب (مثل حذف اسنپ‌شات یا تغییر نگهداشت)؛ ۳) مصون‌سازی داده‌های بازیابی با WORM/immutability، قفل‌های نگهداشت و یک خزانه بازیابی ایزوله که کلیدها و سیاست‌هایش خارج از دامنه اصلی کنترل شود. برای عملیاتی‌سازی نیز باید سیاست‌ها را کدنویسی، ممیزی و به‌طور منظم سناریوهای حذف بکاپ/کاهش نگهداشت را تمرین و بازیابی از نسخه‌های غیرقابل‌تغییر را تست کرد. نتیجه: تعمیم zero trust به ذخیره‌سازی، آخرین خط دفاع—یعنی بکاپ—را واقعاً مقاوم می‌کند.
#ZeroTrust #Ransomware #StorageSecurity #APIProtection #WORM #BackupImmutability #IdentitySecurity
🟣لینک مقاله:
https://www.csoonline.com/article/4061829/what-i-learned-extending-zero-trust-to-the-storage-layer.html?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
CSO Online
What I learned extending zero trust to the storage layer
Think your backups are safe? Attackers don’t. Zero trust for storage may be the only thing standing between you and disaster.
❤1
🔵 عنوان مقاله
How We Systematized Technical Debt Management in Our QA Team
🟢 خلاصه مقاله:
Ilia Golos نشان می‌دهد که «بدهی فنی» مانند باگ‌ها اجتناب‌ناپذیر است، اما اگر سیستماتیک مدیریت شود به‌جای مانع، به اهرمی برای سرعت و پایداری تبدیل می‌شود. او برای تیم‌های QA یک چارچوب عملی پیشنهاد می‌کند: دسته‌بندی شفاف بدهی‌ها (مثل کد تست، تست‌های flaky یا کند، محیط و پیکربندی، داده تست، شکاف‌های پوشش و فرایندها)، نگه‌داشتن همه موارد در یک بک‌لاگ واحد با برچسب‌های یکنواخت، و اولویت‌بندی بر مبنای ریسک و اثر روی کاربر. برای حفظ تمرکز، بخشی از ظرفیت هر اسپرینت به بدهی اختصاص می‌یابد یا اسپرینت‌های ویژه بدهی برگزار می‌شود؛ افزودن کنترل‌های بدهی به Definition of Done از ایجاد بدهی جدید جلوگیری می‌کند و داشبوردهایی مانند نرخ flaky، زمان اجرای تست و سن بدهی، تصمیم‌گیری را داده‌محور می‌سازند. در عمل، توصیه‌ها شامل بازآرایی کد تست، حذف تست‌های منسوخ، پایدارسازی flakyها، خودکارسازی بررسی‌های تکراری، بازتولیدپذیر کردن محیط و داده، و مشارکت نزدیک با توسعه و محصول برای توازن میان قابلیت‌ها و ریسک است. با مالکیت روشن، الگوی ثبت ساده، بازبینی‌های دوره‌ای و قانون «جلوگیری از خونریزی» برای بدهی‌های جدید، مدیریت بدهی تدریجی اما پیوسته می‌شود و به انتشارهای سریع‌تر و قابل‌اعتمادتر می‌انجامد.
#TechnicalDebt #QualityAssurance #SoftwareTesting #TestAutomation #AgileTesting #DevOps #QA #EngineeringManagement
🟣لینک مقاله:
https://cur.at/196LoVa?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
How We Systematized Technical Debt Management in Our QA Team
🟢 خلاصه مقاله:
Ilia Golos نشان می‌دهد که «بدهی فنی» مانند باگ‌ها اجتناب‌ناپذیر است، اما اگر سیستماتیک مدیریت شود به‌جای مانع، به اهرمی برای سرعت و پایداری تبدیل می‌شود. او برای تیم‌های QA یک چارچوب عملی پیشنهاد می‌کند: دسته‌بندی شفاف بدهی‌ها (مثل کد تست، تست‌های flaky یا کند، محیط و پیکربندی، داده تست، شکاف‌های پوشش و فرایندها)، نگه‌داشتن همه موارد در یک بک‌لاگ واحد با برچسب‌های یکنواخت، و اولویت‌بندی بر مبنای ریسک و اثر روی کاربر. برای حفظ تمرکز، بخشی از ظرفیت هر اسپرینت به بدهی اختصاص می‌یابد یا اسپرینت‌های ویژه بدهی برگزار می‌شود؛ افزودن کنترل‌های بدهی به Definition of Done از ایجاد بدهی جدید جلوگیری می‌کند و داشبوردهایی مانند نرخ flaky، زمان اجرای تست و سن بدهی، تصمیم‌گیری را داده‌محور می‌سازند. در عمل، توصیه‌ها شامل بازآرایی کد تست، حذف تست‌های منسوخ، پایدارسازی flakyها، خودکارسازی بررسی‌های تکراری، بازتولیدپذیر کردن محیط و داده، و مشارکت نزدیک با توسعه و محصول برای توازن میان قابلیت‌ها و ریسک است. با مالکیت روشن، الگوی ثبت ساده، بازبینی‌های دوره‌ای و قانون «جلوگیری از خونریزی» برای بدهی‌های جدید، مدیریت بدهی تدریجی اما پیوسته می‌شود و به انتشارهای سریع‌تر و قابل‌اعتمادتر می‌انجامد.
#TechnicalDebt #QualityAssurance #SoftwareTesting #TestAutomation #AgileTesting #DevOps #QA #EngineeringManagement
🟣لینک مقاله:
https://cur.at/196LoVa?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
How We Systematized Technical Debt Management in Our QA Team
I'll share the steps we took, and the metrics that helped us turn technical debt into a manageable part of our workflow.
❤1
🔵 عنوان مقاله
Microsoft shop? Huntress helps you get better ROI from your licenses (Sponsor)
🟢 خلاصه مقاله:
**اگر از لایسنس‌های Microsoft استفاده می‌کنید اما مطمئن نیستید از توان کامل ابزارهای امنیتی آن بهره می‌برید، Huntress با Managed EDR و ITDR کمک می‌کند ارزش واقعی دریافت کنید. با پایش 24/7 توسط SOC و شکار تهدید توسط کارشناسان، هشدارهای مهم سریع‌تر شناسایی می‌شوند و نویز کاهش می‌یابد. Huntress به‌عنوان شریک رسمی Microsoft بدون نیاز به rip-and-replace با محیط فعلی شما یکپارچه می‌شود، مثبت‌های کاذب را کمتر می‌کند و با MTTR پیشرو در صنعت، پاسخ‌گویی و مهار رخدادها را تسریع می‌سازد. برای بهبود ROI از ابزارهای موجود و مشاهده عملکرد در محیط خود، دمو رزرو کنید.
#MicrosoftSecurity #Huntress #EDR #ITDR #SOC #MTTR #ThreatHunting #CyberSecurity
🟣لینک مقاله:
https://www.huntress.com/why-huntress/partnerships/huntress-and-microsoft-better-together?utm_source=tldr&utm_medium=email&utm_campaign=Cy25-09-camp-platform-global-prospect-iis-x-tldr_newsletter_0926
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Microsoft shop? Huntress helps you get better ROI from your licenses (Sponsor)
🟢 خلاصه مقاله:
**اگر از لایسنس‌های Microsoft استفاده می‌کنید اما مطمئن نیستید از توان کامل ابزارهای امنیتی آن بهره می‌برید، Huntress با Managed EDR و ITDR کمک می‌کند ارزش واقعی دریافت کنید. با پایش 24/7 توسط SOC و شکار تهدید توسط کارشناسان، هشدارهای مهم سریع‌تر شناسایی می‌شوند و نویز کاهش می‌یابد. Huntress به‌عنوان شریک رسمی Microsoft بدون نیاز به rip-and-replace با محیط فعلی شما یکپارچه می‌شود، مثبت‌های کاذب را کمتر می‌کند و با MTTR پیشرو در صنعت، پاسخ‌گویی و مهار رخدادها را تسریع می‌سازد. برای بهبود ROI از ابزارهای موجود و مشاهده عملکرد در محیط خود، دمو رزرو کنید.
#MicrosoftSecurity #Huntress #EDR #ITDR #SOC #MTTR #ThreatHunting #CyberSecurity
🟣لینک مقاله:
https://www.huntress.com/why-huntress/partnerships/huntress-and-microsoft-better-together?utm_source=tldr&utm_medium=email&utm_campaign=Cy25-09-camp-platform-global-prospect-iis-x-tldr_newsletter_0926
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Huntress
Huntress & Microsoft: Better Together | Huntress
Microsoft 365 is at the heart of your business, level up your cybersecurity with Huntress Managed EDR, ITDR, & Managed Microsoft Defender while extracting the value of your existing Microsoft investments.
🔵 عنوان مقاله
Mitigating supply chain attacks (2 minute read)
🟢 خلاصه مقاله:
pnpm v10 برای کاهش ریسک حملات زنجیره تأمین دو تغییر مهم اعمال می‌کند: ۱) اجرای خودکار postinstall در وابستگی‌ها به‌صورت پیش‌فرض غیرفعال شده و فقط بسته‌هایی که واقعاً به اسکریپت‌های ساخت نیاز دارند با اجازه صریح (whitelist/allowlist) اجرا می‌شوند؛ ۲) تنظیم minimumReleaseAge نصب نسخه‌های تازه‌منتشرشده را برای مدتی به‌تعویق می‌اندازد تا قبل از نصب، زمان لازم برای شناسایی و گزارش بسته‌های مخرب فراهم شود. حاصل این رویکرد، کاهش اجرای ناخواسته کد و ایجاد یک حاشیه امن برای شناسایی تهدیدات است، با هزینه‌ای اندک در سرعت به‌روزرسانی. راهکار عملی برای تیم‌ها: مشخص‌کردن بسته‌هایی که واقعاً به اسکریپت نیاز دارند و allowlist کردن آن‌ها، و تنظیم حد انتظار مناسب برای minimumReleaseAge بر اساس سطح ریسک محیط توسعه و تولید.
#pnpm #SupplyChainSecurity #OpenSourceSecurity #JavaScript #NodeJS #DevSecOps #PackageManagers #SoftwareSupplyChain
🟣لینک مقاله:
https://pnpm.io/supply-chain-security?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Mitigating supply chain attacks (2 minute read)
🟢 خلاصه مقاله:
pnpm v10 برای کاهش ریسک حملات زنجیره تأمین دو تغییر مهم اعمال می‌کند: ۱) اجرای خودکار postinstall در وابستگی‌ها به‌صورت پیش‌فرض غیرفعال شده و فقط بسته‌هایی که واقعاً به اسکریپت‌های ساخت نیاز دارند با اجازه صریح (whitelist/allowlist) اجرا می‌شوند؛ ۲) تنظیم minimumReleaseAge نصب نسخه‌های تازه‌منتشرشده را برای مدتی به‌تعویق می‌اندازد تا قبل از نصب، زمان لازم برای شناسایی و گزارش بسته‌های مخرب فراهم شود. حاصل این رویکرد، کاهش اجرای ناخواسته کد و ایجاد یک حاشیه امن برای شناسایی تهدیدات است، با هزینه‌ای اندک در سرعت به‌روزرسانی. راهکار عملی برای تیم‌ها: مشخص‌کردن بسته‌هایی که واقعاً به اسکریپت نیاز دارند و allowlist کردن آن‌ها، و تنظیم حد انتظار مناسب برای minimumReleaseAge بر اساس سطح ریسک محیط توسعه و تولید.
#pnpm #SupplyChainSecurity #OpenSourceSecurity #JavaScript #NodeJS #DevSecOps #PackageManagers #SoftwareSupplyChain
🟣لینک مقاله:
https://pnpm.io/supply-chain-security?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
pnpm.io
Mitigating supply chain attacks | pnpm
Sometimes npm packages are compromised and published with malware. Luckily, there are companies like [Socket], [Snyk], and [Aikido] that detect these compromised packages early. The npm registry usually removes the affected versions within hours. However…
چرا از جاوا و پایتون برای نرم افزارهای سیستم های هوافضا نمیشه استفاده کرد؟
1-قطعیت (Determinism):
در زبان هایی مثل جاوا و پایتون به خاطر وجود garbage collection و مبتنی بر JVM بودن اجرای برنامه دقیقا قابل پیش بینی نیست. ممکنه برنامه یه لحظه به خاطر garbage collector متوقف بشه یا pause کنه. تو نرم افزارهای real time همچین چیزی قابل قبول نیست.
به عبارت دیگه یه حلقه توی جاوا یه بار ممکنه یک میلی ثانیه طول بکشه اما دفعه بعد 5 میلی ثانیه طول بکشه دلیل این امر اینه که JIT و gc معلوم نیست کی عمل می کنن و حافظه رو پس می گیرن. پایتون هم به همین دلیل که gc داره عملکردش این شکلیه.
2-زمانبندی سخت گیرانه(Hard real-time constraints): نرم افزارهای هوافضا باید مشخص، کوتاه و قطعی واکنش نشان دهند اما جاوا و پایتون همچین تضمینی نمی دهند.
3-ایمنی و استانداردها :
صنعت هوافضا از استانداردهایی مثل DO-178C پیروی می‌کند. Ada و C ابزارها و کتابخانه‌های تأییدشده‌ای برای این استاندارد دارند اما برای جاوا و پایتون چنین پشتیبانی و تأیید رسمی بسیار محدود یا تقریباً وجود ندارد.
4-کارایی (Performance & Footprint):
پایتون کنده چون مفسریه جاوا هم به خاطر JVM و مدیریت حافظه سربار زیادی داره که خب توی سیستم های هوافضا که سرعت مهمه و منابع سخت افزاری محدودی داریم نمیشه یه برنامه کند و برنامه ای که کلی منابع میخواد رو اجرا کنیم.
در نهایت باید بگم که زبان هایی که باهاشون نرم افزارهای سیستم های هوافضا، نظامی و حساس رو میسازن Ada-Spark ada - C و جدیدا Rust هستند.
<Mohsen Shojaei Yeganeh/>
👇👇👇👇👇👇👇
@software_Labdon
1-قطعیت (Determinism):
در زبان هایی مثل جاوا و پایتون به خاطر وجود garbage collection و مبتنی بر JVM بودن اجرای برنامه دقیقا قابل پیش بینی نیست. ممکنه برنامه یه لحظه به خاطر garbage collector متوقف بشه یا pause کنه. تو نرم افزارهای real time همچین چیزی قابل قبول نیست.
به عبارت دیگه یه حلقه توی جاوا یه بار ممکنه یک میلی ثانیه طول بکشه اما دفعه بعد 5 میلی ثانیه طول بکشه دلیل این امر اینه که JIT و gc معلوم نیست کی عمل می کنن و حافظه رو پس می گیرن. پایتون هم به همین دلیل که gc داره عملکردش این شکلیه.
2-زمانبندی سخت گیرانه(Hard real-time constraints): نرم افزارهای هوافضا باید مشخص، کوتاه و قطعی واکنش نشان دهند اما جاوا و پایتون همچین تضمینی نمی دهند.
3-ایمنی و استانداردها :
صنعت هوافضا از استانداردهایی مثل DO-178C پیروی می‌کند. Ada و C ابزارها و کتابخانه‌های تأییدشده‌ای برای این استاندارد دارند اما برای جاوا و پایتون چنین پشتیبانی و تأیید رسمی بسیار محدود یا تقریباً وجود ندارد.
4-کارایی (Performance & Footprint):
پایتون کنده چون مفسریه جاوا هم به خاطر JVM و مدیریت حافظه سربار زیادی داره که خب توی سیستم های هوافضا که سرعت مهمه و منابع سخت افزاری محدودی داریم نمیشه یه برنامه کند و برنامه ای که کلی منابع میخواد رو اجرا کنیم.
در نهایت باید بگم که زبان هایی که باهاشون نرم افزارهای سیستم های هوافضا، نظامی و حساس رو میسازن Ada-Spark ada - C و جدیدا Rust هستند.
<Mohsen Shojaei Yeganeh/>
👇👇👇👇👇👇👇
@software_Labdon
🔵 عنوان مقاله
Gcore Radar Report Reveals 41% Surge in DDoS Attack Volumes (4 minute read)
🟢 خلاصه مقاله:
گزارش Radar شرکت Gcore برای نیمه اول 2025 نشان می‌دهد حجم حملات DDoS نسبت به سال قبل ۴۱٪ افزایش یافته و اوج ۲.۲ Tbps را ثبت کرده است. تمرکز مهاجمان از حوزه بازی به سمت بخش‌های مالی و فناوری تغییر کرده و آن‌ها با کارزارهای طولانی و چندبرداری تلاش می‌کنند از دفاع‌های کوتاه‌مدت عبور کنند. پیامد این روند، نیاز به حفاظت همیشه‌فعال، شناسایی رفتاری، اسکرابینگ خودکار ترافیک در لبه و پوشش جامع لایه‌های L3 تا L7 است.
#DDoS #Cybersecurity #Gcore #ThreatIntelligence #NetworkSecurity #Fintech #TechSector #DDoSMitigation
🟣لینک مقاله:
https://hackread.com/gcore-radar-report-reveals-41-surge-in-ddos-attack-volumes/?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Gcore Radar Report Reveals 41% Surge in DDoS Attack Volumes (4 minute read)
🟢 خلاصه مقاله:
گزارش Radar شرکت Gcore برای نیمه اول 2025 نشان می‌دهد حجم حملات DDoS نسبت به سال قبل ۴۱٪ افزایش یافته و اوج ۲.۲ Tbps را ثبت کرده است. تمرکز مهاجمان از حوزه بازی به سمت بخش‌های مالی و فناوری تغییر کرده و آن‌ها با کارزارهای طولانی و چندبرداری تلاش می‌کنند از دفاع‌های کوتاه‌مدت عبور کنند. پیامد این روند، نیاز به حفاظت همیشه‌فعال، شناسایی رفتاری، اسکرابینگ خودکار ترافیک در لبه و پوشش جامع لایه‌های L3 تا L7 است.
#DDoS #Cybersecurity #Gcore #ThreatIntelligence #NetworkSecurity #Fintech #TechSector #DDoSMitigation
🟣لینک مقاله:
https://hackread.com/gcore-radar-report-reveals-41-surge-in-ddos-attack-volumes/?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Hackread
Gcore Radar Report Reveals 41% Surge in DDoS Attack Volumes
Luxembourg, Luxembourg, 25th September 2025, CyberNewsWire
🔵 عنوان مقاله
Critical Vulnerability in Salesforce AgentForce Exposed (2 minute read)
🟢 خلاصه مقاله:
** محققان Noma Security یک آسیب‌پذیری بحرانی با امتیاز CVSS 9.4 در AgentForce متعلق به Salesforce شناسایی کردند که امکان افشای داده از طریق indirect prompt injection را فراهم می‌کرد. مهاجم می‌توانست دستورهای مخفی را در Web-to-Lead قرار دهد تا به‌عنوان داده مشتری ذخیره شود و هنگام پرس‌وجوی بعدی کاربر از AgentForce، این دستورها اجرا شده و به افشای اطلاعات منجر شوند. Salesforce با اعمال Trusted URLs و ایمن‌سازی مجدد یک دامنه منقضی‌شده این مشکل را برطرف کرد. این مورد نشان می‌دهد ورودی‌های غیرقابل‌اعتماد در جریان‌های کاری مبتنی بر هوش مصنوعی می‌توانند خطرناک باشند و نیاز به کنترل‌های فنی و آگاهی کاربران وجود دارد.
#Salesforce #AgentForce #PromptInjection #AIsecurity #DataExfiltration #CVSS #WebSecurity #NomaSecurity
🟣لینک مقاله:
https://www.infosecurity-magazine.com/news/critical-flaw-salesforce-agentforce/?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Critical Vulnerability in Salesforce AgentForce Exposed (2 minute read)
🟢 خلاصه مقاله:
** محققان Noma Security یک آسیب‌پذیری بحرانی با امتیاز CVSS 9.4 در AgentForce متعلق به Salesforce شناسایی کردند که امکان افشای داده از طریق indirect prompt injection را فراهم می‌کرد. مهاجم می‌توانست دستورهای مخفی را در Web-to-Lead قرار دهد تا به‌عنوان داده مشتری ذخیره شود و هنگام پرس‌وجوی بعدی کاربر از AgentForce، این دستورها اجرا شده و به افشای اطلاعات منجر شوند. Salesforce با اعمال Trusted URLs و ایمن‌سازی مجدد یک دامنه منقضی‌شده این مشکل را برطرف کرد. این مورد نشان می‌دهد ورودی‌های غیرقابل‌اعتماد در جریان‌های کاری مبتنی بر هوش مصنوعی می‌توانند خطرناک باشند و نیاز به کنترل‌های فنی و آگاهی کاربران وجود دارد.
#Salesforce #AgentForce #PromptInjection #AIsecurity #DataExfiltration #CVSS #WebSecurity #NomaSecurity
🟣لینک مقاله:
https://www.infosecurity-magazine.com/news/critical-flaw-salesforce-agentforce/?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Infosecurity Magazine
Critical Vulnerability in Salesforce AgentForce Exposed
Critical flaw ForcedLeak in Salesforce's AgentForce allows CRM data theft via prompt injection
❤1
🔵 عنوان مقاله
Malicious Rust Packages on Crates.io Steal Crypto Wallet Keys (2 minute read)
🟢 خلاصه مقاله:
پژوهشگران Socket دو بسته مخرب Rust را در crates.io شناسایی کردند که با جا زدن خود به‌جای fast_log، علاوه بر عملکرد عادی، کدی برای اسکن محیط و فایل‌های پروژه داشتند تا رشته‌های Hex شبیه کلید خصوصی Ethereum، رشته‌های Base58 شبیه کلیدهای Solana و آرایه‌های بایت براکت‌دار را پیدا کرده و آن‌ها را به سرور مهاجم ارسال کنند. این یک حمله supply-chain است که می‌تواند به افشای کلیدها و سرقت دارایی‌ها منجر شود. به توسعه‌دهندگان توصیه می‌شود بسته‌های مشکوک را حذف، کلیدهای Ethereum و Solana را تعویض، تاریخچه مخزن را برای افشای تصادفی اسرار بررسی، وابستگی‌ها را pin کنند و از ابزارهای امنیتی مانند cargo-audit، cargo-vet و اسکن رازها در کنار کمینه‌سازی دسترسی اسرار در CI استفاده کنند.
#Rust #cratesio #SupplyChain #CryptoSecurity #Ethereum #Solana #OpenSourceSecurity #Malware
🟣لینک مقاله:
https://www.bleepingcomputer.com/news/security/malicious-rust-packages-on-cratesio-steal-crypto-wallet-keys/?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Malicious Rust Packages on Crates.io Steal Crypto Wallet Keys (2 minute read)
🟢 خلاصه مقاله:
پژوهشگران Socket دو بسته مخرب Rust را در crates.io شناسایی کردند که با جا زدن خود به‌جای fast_log، علاوه بر عملکرد عادی، کدی برای اسکن محیط و فایل‌های پروژه داشتند تا رشته‌های Hex شبیه کلید خصوصی Ethereum، رشته‌های Base58 شبیه کلیدهای Solana و آرایه‌های بایت براکت‌دار را پیدا کرده و آن‌ها را به سرور مهاجم ارسال کنند. این یک حمله supply-chain است که می‌تواند به افشای کلیدها و سرقت دارایی‌ها منجر شود. به توسعه‌دهندگان توصیه می‌شود بسته‌های مشکوک را حذف، کلیدهای Ethereum و Solana را تعویض، تاریخچه مخزن را برای افشای تصادفی اسرار بررسی، وابستگی‌ها را pin کنند و از ابزارهای امنیتی مانند cargo-audit، cargo-vet و اسکن رازها در کنار کمینه‌سازی دسترسی اسرار در CI استفاده کنند.
#Rust #cratesio #SupplyChain #CryptoSecurity #Ethereum #Solana #OpenSourceSecurity #Malware
🟣لینک مقاله:
https://www.bleepingcomputer.com/news/security/malicious-rust-packages-on-cratesio-steal-crypto-wallet-keys/?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
BleepingComputer
Malicious Rust packages on Crates.io steal crypto wallet keys
Two malicious packages with nearly 8,500 downloads in Rust's official crate repository scanned developers' systems to steal cryptocurrency private keys and other secrets.
🔵 عنوان مقاله
Playwright Selectors That Don't Flake — 7 Rules
🟢 خلاصه مقاله:
مقاله‌ی Roshan Manjushree Adhikari راه‌های کاهش flakiness ناشی از selectorها در Playwright را توضیح می‌دهد و تأکید می‌کند که به‌جای اتکا به retry، باید سراغ selectorهای پایدار و استفاده‌ی درست از Locator API و auto-waiting رفت. او هفت قاعده‌ی کاربردی پیشنهاد می‌کند: تکیه بر locatorهای معنایی مثل getByRole/getByLabel/getByText؛ استفاده از data-testid به‌جای کلاس‌ها/IDهای پویا؛ پرهیز از selectorهای موقعیتی مثل nth-child و محدود کردن دامنه‌ی جست‌وجو؛ بهره‌گیری از locator() و expect() با انتظارهای درون‌ساخت به‌جای sleep؛ همگام‌سازی با وضعیت واقعی UI و انجام اکشن‌های کاربرمحور؛ نزدیک‌کردن selectorها به نشانه‌گذاری دسترس‌پذیر و تمرکز آن‌ها در لایه‌ی مشترک؛ و رصد و رفع ریشه‌ای تست‌های flaky به‌جای retry سراسری. این توصیه‌ها در سایر test frameworks نیز کارآمد هستند.
#Playwright #TestAutomation #Selectors #FlakyTests #E2E #QA #Testing
🟣لینک مقاله:
https://cur.at/QPNtNUw?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Playwright Selectors That Don't Flake — 7 Rules
🟢 خلاصه مقاله:
مقاله‌ی Roshan Manjushree Adhikari راه‌های کاهش flakiness ناشی از selectorها در Playwright را توضیح می‌دهد و تأکید می‌کند که به‌جای اتکا به retry، باید سراغ selectorهای پایدار و استفاده‌ی درست از Locator API و auto-waiting رفت. او هفت قاعده‌ی کاربردی پیشنهاد می‌کند: تکیه بر locatorهای معنایی مثل getByRole/getByLabel/getByText؛ استفاده از data-testid به‌جای کلاس‌ها/IDهای پویا؛ پرهیز از selectorهای موقعیتی مثل nth-child و محدود کردن دامنه‌ی جست‌وجو؛ بهره‌گیری از locator() و expect() با انتظارهای درون‌ساخت به‌جای sleep؛ همگام‌سازی با وضعیت واقعی UI و انجام اکشن‌های کاربرمحور؛ نزدیک‌کردن selectorها به نشانه‌گذاری دسترس‌پذیر و تمرکز آن‌ها در لایه‌ی مشترک؛ و رصد و رفع ریشه‌ای تست‌های flaky به‌جای retry سراسری. این توصیه‌ها در سایر test frameworks نیز کارآمد هستند.
#Playwright #TestAutomation #Selectors #FlakyTests #E2E #QA #Testing
🟣لینک مقاله:
https://cur.at/QPNtNUw?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
Playwright Selectors That Don’t Flake — 7 Rules
Your test passes today, fails tomorrow, and nobody touched the code. Most of the time, it’s not Playwright’s fault — it’s your selectors.
🔵 عنوان مقاله
RtlHijack (GitHub Repo)
🟢 خلاصه مقاله:
RtlHijack (GitHub Repo) مجموعه‌ای از اسکریپت‌هاست که نشان می‌دهد چگونه می‌توان برخی توابع Rtl* در Windows را به‌صورت ناخواسته برای ایجاد «primitive»های جایگزین خواندن و نوشتن حافظه به‌کار گرفت. هدف پروژه، آموزش و پژوهش امنیتی است تا پژوهشگران و مدافعان بتوانند رفتارهای سطح پایین و پیامدهای امنیتی آن‌ها را بهتر درک کنند. بر کاربرد اخلاقی و آموزشی تأکید دارد، کلاس‌های رفتاری را توضیح می‌دهد و به مدافعان برای شناسایی الگوهای غیرعادی در استفاده از APIها، بهبود پایش و سخت‌سازی کمک می‌کند؛ بدون ارائه جزئیات اجرایی یا روش‌های مرحله‌به‌مرحله.
#RtlHijack #CyberSecurity #ExploitResearch #WindowsInternals #MemorySafety #BlueTeam #RedTeam #GitHub
🟣لینک مقاله:
https://github.com/kleiton0x00/RtlHijack?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
RtlHijack (GitHub Repo)
🟢 خلاصه مقاله:
RtlHijack (GitHub Repo) مجموعه‌ای از اسکریپت‌هاست که نشان می‌دهد چگونه می‌توان برخی توابع Rtl* در Windows را به‌صورت ناخواسته برای ایجاد «primitive»های جایگزین خواندن و نوشتن حافظه به‌کار گرفت. هدف پروژه، آموزش و پژوهش امنیتی است تا پژوهشگران و مدافعان بتوانند رفتارهای سطح پایین و پیامدهای امنیتی آن‌ها را بهتر درک کنند. بر کاربرد اخلاقی و آموزشی تأکید دارد، کلاس‌های رفتاری را توضیح می‌دهد و به مدافعان برای شناسایی الگوهای غیرعادی در استفاده از APIها، بهبود پایش و سخت‌سازی کمک می‌کند؛ بدون ارائه جزئیات اجرایی یا روش‌های مرحله‌به‌مرحله.
#RtlHijack #CyberSecurity #ExploitResearch #WindowsInternals #MemorySafety #BlueTeam #RedTeam #GitHub
🟣لینک مقاله:
https://github.com/kleiton0x00/RtlHijack?utm_source=tldrinfosec
➖➖➖➖➖➖➖➖
👑 @software_Labdon
GitHub
GitHub - kleiton0x00/RtlHijack: Alternative Read and Write primitives using Rtl* functions the unintended way.
Alternative Read and Write primitives using Rtl* functions the unintended way. - kleiton0x00/RtlHijack
❤1
این کتاب خیلی ساده و روان توضیح میده چرا Rust اینقدر سر و صدا کرده و چرا خیلی‌ها دارن سمتش میرن:
نشون میده چطوری با سیستم ownership و borrowing میشه حافظه رو بدون دردسر مدیریت کرد
توضیح میده چرا توی Rust باگ‌هایی مثل null pointer یا data race کلاً از همون اول جلوی راهت سبز نمی‌شن
یاد میده چطوری میشه به راحتی برنامه‌های چندنخی و امن نوشت، بدون استرس خطاهای عجیب غریب
تأکید میکنه که همه‌ی این امکانات رو می‌گیری، ولی سرعتش در حد C/C++ باقی می‌مونه
نشون میده چطوری با سیستم ownership و borrowing میشه حافظه رو بدون دردسر مدیریت کرد
توضیح میده چرا توی Rust باگ‌هایی مثل null pointer یا data race کلاً از همون اول جلوی راهت سبز نمی‌شن
یاد میده چطوری میشه به راحتی برنامه‌های چندنخی و امن نوشت، بدون استرس خطاهای عجیب غریب
تأکید میکنه که همه‌ی این امکانات رو می‌گیری، ولی سرعتش در حد C/C++ باقی می‌مونه
❤1
🔵 عنوان مقاله
Testing and Programming Are Not Separate Disciplines
🟢 خلاصه مقاله:
** این یادآوری از Ravisuriya Eswara تأکید می‌کند که توسعه و تست نرم‌افزار باید یک فرایند یکپارچه باشند، نه دو رشته جدا. با وارد کردن تست در متن کار روزانه—از تعریف معیارهای پذیرش و شناسایی ریسک‌ها تا نوشتن تست‌ها کنار کد، اجرای TDD و پایپ‌لاین‌های CI/CD—کیفیت از ابتدا طراحی می‌شود، نه در انتها ارزیابی.
این رویکرد مزایایی مانند کاهش نقیصه‌های تولید، بازخورد سریع‌تر، تحویل قابل‌پیش‌بینی، تجربه کاربری بهتر و هزینه نگهداری کمتر دارد. همکاری جایگزین تحویل‌های مرحله‌ای می‌شود: توسعه‌دهندگان بر طراحیِ قابل‌تست تمرکز می‌کنند و تسترها با نگاه اکتشافی و کل‌نگر کیفیت را غنی می‌کنند؛ اتوماسیون و تست اکتشافی مکمل هم‌اند. نتیجه، چرخه‌ای سالم‌تر و محصولی پایدارتر در راستای اصول Agile و DevOps است.
#تست_نرم‌افزار #برنامه‌نویسی #کیفیت #DevOps #TDD #CI_CD #Agile #مهندسی_نرم‌افزار
🟣لینک مقاله:
https://cur.at/N39OqUZ?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Testing and Programming Are Not Separate Disciplines
🟢 خلاصه مقاله:
** این یادآوری از Ravisuriya Eswara تأکید می‌کند که توسعه و تست نرم‌افزار باید یک فرایند یکپارچه باشند، نه دو رشته جدا. با وارد کردن تست در متن کار روزانه—از تعریف معیارهای پذیرش و شناسایی ریسک‌ها تا نوشتن تست‌ها کنار کد، اجرای TDD و پایپ‌لاین‌های CI/CD—کیفیت از ابتدا طراحی می‌شود، نه در انتها ارزیابی.
این رویکرد مزایایی مانند کاهش نقیصه‌های تولید، بازخورد سریع‌تر، تحویل قابل‌پیش‌بینی، تجربه کاربری بهتر و هزینه نگهداری کمتر دارد. همکاری جایگزین تحویل‌های مرحله‌ای می‌شود: توسعه‌دهندگان بر طراحیِ قابل‌تست تمرکز می‌کنند و تسترها با نگاه اکتشافی و کل‌نگر کیفیت را غنی می‌کنند؛ اتوماسیون و تست اکتشافی مکمل هم‌اند. نتیجه، چرخه‌ای سالم‌تر و محصولی پایدارتر در راستای اصول Agile و DevOps است.
#تست_نرم‌افزار #برنامه‌نویسی #کیفیت #DevOps #TDD #CI_CD #Agile #مهندسی_نرم‌افزار
🟣لینک مقاله:
https://cur.at/N39OqUZ?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Blogspot
Testing and Programming Are Not Separate Disciplines
Programming, Testing, Coding, Skills, Practice, Thinking, Debugging, Programming Languages, Data Structures, Tester, SDET, Developer, Myth
❤1
🔵 عنوان مقاله
The Over-Framework Trap: Preventing the Maze of Test Complexity
🟢 خلاصه مقاله:
Roman Kostenko هشدار می‌دهد به دام «Over‑Framework» نیفتید؛ جایی که چارچوب‌های تست با لایه‌های اضافی، wrapperها و DSLهای پیچیده بهره‌وری را کم و نگهداری را سخت می‌کنند. او توصیه می‌کند از ساده‌ترین راهکار شروع کنید، تا حد امکان از ابزارها و الگوهای پذیرفته‌شده استفاده کنید، و فقط زمانی abstraction اضافه کنید که درد تکرار واقعاً احساس می‌شود—آن هم به سبک مینیمال تا خوانایی تست‌ها حفظ شود. همچنین بر قابلیت اتکا و مشاهده‌پذیری تأکید دارد: داده‌ی تست قطعی، setup/teardown تمیز، پیام خطای مفید، لاگ مختصر و سریع‌بودن چرخه‌ی بازخورد. چارچوب را به‌تدریج و بر اساس نیازهای واقعی رشد دهید، بخش‌های بلااستفاده را حذف کنید و با مستندسازی سبک و بازبینی‌های سبک از پیچیدگی ناخواسته جلوگیری کنید.
#TestAutomation #SoftwareTesting #QA #TestFramework #Simplicity #CleanCode #DevOps #BestPractices
🟣لینک مقاله:
https://cur.at/NeRvNG1?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
The Over-Framework Trap: Preventing the Maze of Test Complexity
🟢 خلاصه مقاله:
Roman Kostenko هشدار می‌دهد به دام «Over‑Framework» نیفتید؛ جایی که چارچوب‌های تست با لایه‌های اضافی، wrapperها و DSLهای پیچیده بهره‌وری را کم و نگهداری را سخت می‌کنند. او توصیه می‌کند از ساده‌ترین راهکار شروع کنید، تا حد امکان از ابزارها و الگوهای پذیرفته‌شده استفاده کنید، و فقط زمانی abstraction اضافه کنید که درد تکرار واقعاً احساس می‌شود—آن هم به سبک مینیمال تا خوانایی تست‌ها حفظ شود. همچنین بر قابلیت اتکا و مشاهده‌پذیری تأکید دارد: داده‌ی تست قطعی، setup/teardown تمیز، پیام خطای مفید، لاگ مختصر و سریع‌بودن چرخه‌ی بازخورد. چارچوب را به‌تدریج و بر اساس نیازهای واقعی رشد دهید، بخش‌های بلااستفاده را حذف کنید و با مستندسازی سبک و بازبینی‌های سبک از پیچیدگی ناخواسته جلوگیری کنید.
#TestAutomation #SoftwareTesting #QA #TestFramework #Simplicity #CleanCode #DevOps #BestPractices
🟣لینک مقاله:
https://cur.at/NeRvNG1?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
The Over-Framework Trap: Preventing the Maze of Test Complexity.
Today I want to talk about something that hurts every developer sooner or later — complexity. Especially in tests. You know the moment: a…
🤡1
🔵 عنوان مقاله
AI Picks Tests To Run On A Bug
🟢 خلاصه مقاله:
این مقاله یک نمونه عملی از کاربست هوش مصنوعی در تست نرم‌افزار را نشان می‌دهد: Gleb Bahmutov توضیح می‌دهد چگونه می‌توان با تحلیل سرنخ‌های مرتبط با باگ—مثل پیام خطا، stack trace، تغییرات اخیر کد و نسبت تاریخی میان بخش‌های کد و تست‌ها—مجموعه‌ای از آزمون‌های واقعاً مرتبط را انتخاب و اجرا کرد. این روش با اجرای هدفمند تست‌ها، زمان بازخورد را کوتاه‌تر و هزینه اجرا را کمتر می‌کند و هم در محیط توسعه محلی و هم در CI قابل استفاده است. در عین حال، با حفظ نظارت انسانی، سنجش دقت و پوشش انتخاب‌ها، ثبت دلایل انتخاب هر تست و در صورت ابهام، بازگشت به اجرای کامل، اعتمادپذیری حفظ می‌شود. نتیجه، چرخه عیب‌یابی سریع‌تر و تمرکز بیشتر روی تست‌هایی است که بیشترین احتمال کشف یا بازتولید باگ را دارند.
#SoftwareTesting #AI #TestAutomation #QualityAssurance #BugFixing #TestSelection #CICD
🟣لینک مقاله:
https://cur.at/QPMAEXI?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
AI Picks Tests To Run On A Bug
🟢 خلاصه مقاله:
این مقاله یک نمونه عملی از کاربست هوش مصنوعی در تست نرم‌افزار را نشان می‌دهد: Gleb Bahmutov توضیح می‌دهد چگونه می‌توان با تحلیل سرنخ‌های مرتبط با باگ—مثل پیام خطا، stack trace، تغییرات اخیر کد و نسبت تاریخی میان بخش‌های کد و تست‌ها—مجموعه‌ای از آزمون‌های واقعاً مرتبط را انتخاب و اجرا کرد. این روش با اجرای هدفمند تست‌ها، زمان بازخورد را کوتاه‌تر و هزینه اجرا را کمتر می‌کند و هم در محیط توسعه محلی و هم در CI قابل استفاده است. در عین حال، با حفظ نظارت انسانی، سنجش دقت و پوشش انتخاب‌ها، ثبت دلایل انتخاب هر تست و در صورت ابهام، بازگشت به اجرای کامل، اعتمادپذیری حفظ می‌شود. نتیجه، چرخه عیب‌یابی سریع‌تر و تمرکز بیشتر روی تست‌هایی است که بیشترین احتمال کشف یا بازتولید باگ را دارند.
#SoftwareTesting #AI #TestAutomation #QualityAssurance #BugFixing #TestSelection #CICD
🟣لینک مقاله:
https://cur.at/QPMAEXI?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Better world by better software
AI Picks Tests To Run On A Bug
In the blog post Test Tag Suggestions Using AI I described a system to pick a testing tag based on a pull request's title and body text. In this blog post, I will make it useful. Whenever a user o
کامپیوترها برای نگهداری و نمایش کاراکترهای یک متن از یه فضای یک بایتی (معادل هشت بیت 0 یا 1) استفاده میکردن
این میزان فضا توی کامپیوتر میتونه شامل 255 حالت مختلف بشه
کامپیوترها برای نشانه‌های گرامری، حروف انگلیسی و عدد از استاندارد اسکی (ASCII) استفاده میکردن
این استاندارد آمریکایی میاد برای هر کاراکتر یه معادل عددی تعریف میکنه
مثلا کاراکتر A در اسکی معادل عدد 65هست
قرار گرفتن این اعداد پشت سر هم در کامپیوتر یک متن رو میسازه
مشابه این استاندارد معادل عددی برای پشتیبانی از تمام زبان‌های دنیا به وجود اومد که یونیکد (Unicode) نام داره
کاراکترهای انگلیسی و اعداد انگلیسی توی یونیکد از همون اعداد استاندارد اسکی استفاده میکنن و در ادامه پشتیبانی از کاراکترهای بقیه زبان‌های دنیا بهش اضافه میشه
یونیکد در حال حاضر دارای چیزی حدود 297,000 معادل عددی برای کاراکترهای مختلف از زبان‌های مختلف، اموجی‌ها و ... هست
فضای یک بایتی برای پشتیبانی از این میزان حالت‌های مختلف کافی نیس
شما برای این جا دادن این میزان از حالت‌های مختلف به شکل بیت کامیپوتر به حداقل سه بایت نیاز دارین
سه بایت میتونه تا حدود 16 میلیون عدد مختلف رو برای شما نگه داری کنه
حالا شما برای نگهداری یک متن که شامل کاراکترهای
یونیکد هست نیاز دارین 3 بایت برای هر کاراکتر اختصاص بدین
کاراکترهای انگلیسی تو یونیکد تنها یک بایت هم براشون کافیه ولی اگه شما برای یه متن انگلیسی، هر کاراکتر رو سه بایت در نظر بگیرین عملا به ازای هر کاراکتر انگلیسی دو بایت فضا رو هدر دادین
مثلا تو یه متن با ده هزار کاراکتر،
یه چیزی حدود 20 کیلوبایت فضای کامپیوتر رو هدر دادین
چه وقتی میخاین ازش استفاده کنین و توی رم هست و چه وقتی که روی هارد دیسک برای استفاده در آینده ذخیره شده
اینجاست که UTF-8 میتونه کمک کنه
این استاندارد که توسط یونیکد تعریف شده به جای اینکه بیاد فضای 3 بایتی به هر کاراکتر
اختصاص بده، میاد از 7 بیت راست یک بایت برای کاراکترهای اسکی استفاده میکنه
و برای کاراکترهای بعدی علاوه بر خود کاراکتر، تعداد بایت مصرف شده برای اون کاراکتر هم داخل بایت اول ذخیره میکنه
یعنی 128 کاراکتر اول اسکی به شکل عادی ذخیره میشن بدون تغییر خاصی با فقط یک بایت فضا
ولی برای کاراکترهای بعدی میاد و داخل بایت اول مشخص میکنه چه میزان فضا برای کاراکتر استفاده شده
این میزان فضا از یک بایت تا چهاربایت میتونه متغیر باشه
حالا چه شکلی اینکارو میکنه
تو یه بایت برای 128 عدد اولیه اسکی، بیت چپ همیشه صفر هست
اما وقتی بیت چپ یک میشه یعنی با یه کاراکتر UTF8 طرف هستیم
همونطور که گفتم هر کاراکتر توی UTF-8 میتونه از یک بایت تا چهاربایت متغیر باشه
کامپیوتر چطور اینو تشخیص میده؟
بیت‌های 1 اولِ بایت رو میشماره تا به عدد 0 صفر برسه
یعنی اگه بایت اول با عدد باینری 110 شروع بشه، یعنی دوبایت فضا استفاده شده
اگه 1110 باشه سه بایت و ...
تو UTF-8 فضای بیت‌های بایت اول بین خود کاراکتر و تعداد بایت تقسیم میشه و متغیره
اما تو بایت‌های دوم و سوم و چهارم همیشه شش تا بیت راست برای خود کاراکتر استفاده میشه و دو بیت دیگه برای هندل کردن ارور تو utf-8 استفاده میشه
امیدوارم تونسته باشم با دانش ناقص خودم شما رو در مورد این انکدینگ رایج دنیای کامپیوتر آشنا کرده باشم
توضیحات دقیق‌تر:
https://en.wikipedia.org/wiki/UTF-8
سایت استفاده شده برای تست بایت UTF-8:
https://utf8-playground.netlify.app/
| <Amir/>
این میزان فضا توی کامپیوتر میتونه شامل 255 حالت مختلف بشه
کامپیوترها برای نشانه‌های گرامری، حروف انگلیسی و عدد از استاندارد اسکی (ASCII) استفاده میکردن
این استاندارد آمریکایی میاد برای هر کاراکتر یه معادل عددی تعریف میکنه
مثلا کاراکتر A در اسکی معادل عدد 65هست
قرار گرفتن این اعداد پشت سر هم در کامپیوتر یک متن رو میسازه
مشابه این استاندارد معادل عددی برای پشتیبانی از تمام زبان‌های دنیا به وجود اومد که یونیکد (Unicode) نام داره
کاراکترهای انگلیسی و اعداد انگلیسی توی یونیکد از همون اعداد استاندارد اسکی استفاده میکنن و در ادامه پشتیبانی از کاراکترهای بقیه زبان‌های دنیا بهش اضافه میشه
یونیکد در حال حاضر دارای چیزی حدود 297,000 معادل عددی برای کاراکترهای مختلف از زبان‌های مختلف، اموجی‌ها و ... هست
فضای یک بایتی برای پشتیبانی از این میزان حالت‌های مختلف کافی نیس
شما برای این جا دادن این میزان از حالت‌های مختلف به شکل بیت کامیپوتر به حداقل سه بایت نیاز دارین
سه بایت میتونه تا حدود 16 میلیون عدد مختلف رو برای شما نگه داری کنه
حالا شما برای نگهداری یک متن که شامل کاراکترهای
یونیکد هست نیاز دارین 3 بایت برای هر کاراکتر اختصاص بدین
کاراکترهای انگلیسی تو یونیکد تنها یک بایت هم براشون کافیه ولی اگه شما برای یه متن انگلیسی، هر کاراکتر رو سه بایت در نظر بگیرین عملا به ازای هر کاراکتر انگلیسی دو بایت فضا رو هدر دادین
مثلا تو یه متن با ده هزار کاراکتر،
یه چیزی حدود 20 کیلوبایت فضای کامپیوتر رو هدر دادین
چه وقتی میخاین ازش استفاده کنین و توی رم هست و چه وقتی که روی هارد دیسک برای استفاده در آینده ذخیره شده
اینجاست که UTF-8 میتونه کمک کنه
این استاندارد که توسط یونیکد تعریف شده به جای اینکه بیاد فضای 3 بایتی به هر کاراکتر
اختصاص بده، میاد از 7 بیت راست یک بایت برای کاراکترهای اسکی استفاده میکنه
و برای کاراکترهای بعدی علاوه بر خود کاراکتر، تعداد بایت مصرف شده برای اون کاراکتر هم داخل بایت اول ذخیره میکنه
یعنی 128 کاراکتر اول اسکی به شکل عادی ذخیره میشن بدون تغییر خاصی با فقط یک بایت فضا
ولی برای کاراکترهای بعدی میاد و داخل بایت اول مشخص میکنه چه میزان فضا برای کاراکتر استفاده شده
این میزان فضا از یک بایت تا چهاربایت میتونه متغیر باشه
حالا چه شکلی اینکارو میکنه
تو یه بایت برای 128 عدد اولیه اسکی، بیت چپ همیشه صفر هست
اما وقتی بیت چپ یک میشه یعنی با یه کاراکتر UTF8 طرف هستیم
همونطور که گفتم هر کاراکتر توی UTF-8 میتونه از یک بایت تا چهاربایت متغیر باشه
کامپیوتر چطور اینو تشخیص میده؟
بیت‌های 1 اولِ بایت رو میشماره تا به عدد 0 صفر برسه
یعنی اگه بایت اول با عدد باینری 110 شروع بشه، یعنی دوبایت فضا استفاده شده
اگه 1110 باشه سه بایت و ...
تو UTF-8 فضای بیت‌های بایت اول بین خود کاراکتر و تعداد بایت تقسیم میشه و متغیره
اما تو بایت‌های دوم و سوم و چهارم همیشه شش تا بیت راست برای خود کاراکتر استفاده میشه و دو بیت دیگه برای هندل کردن ارور تو utf-8 استفاده میشه
امیدوارم تونسته باشم با دانش ناقص خودم شما رو در مورد این انکدینگ رایج دنیای کامپیوتر آشنا کرده باشم
توضیحات دقیق‌تر:
https://en.wikipedia.org/wiki/UTF-8
سایت استفاده شده برای تست بایت UTF-8:
https://utf8-playground.netlify.app/
| <Amir/>
👍1🕊1
🔵 عنوان مقاله
How to Contribute Meaningfully in Feature Planning
🟢 خلاصه مقاله:
**این مقاله نشان می‌دهد تسترها با طرح پرسش‌های هدفمند می‌توانند از ابتدای برنامه‌ریزی فیچر، ارزش بسازند. محورهای کلیدی شامل روشن‌کردن مسئله و مخاطب، معیارهای موفقیت و محدوده، و ثبت معیارهای پذیرش شفاف است. سپس باید ریسک‌ها و پوشش را زودهنگام آشکار کرد: مسیرهای خطا و لبه، یکپارچگی‌ها و جریان داده، و نیازهای غیرکارکردی مانند امنیت، حریم خصوصی، عملکرد، دسترس‌پذیری و بومی‌سازی. تمرکز بر تست‌پذیری نیز حیاتی است: مشاهده‌پذیری با لاگ و متریک، استراتژی اتوماسیون در لایه‌های مختلف، مدیریت داده آزمایشی و برابری محیط‌ها، و استفاده از feature flag، mock و sandbox برای交交交交交交. در نهایت، برنامه عرضه و یادگیری را تعریف کنید: rollout مرحله‌ای یا A/B، پایش و هشدار، و برنامه بازگشت. به‌گفته Mona M. Abd El-Rahman داشتن یک بانک پرسش آماده، تستر را از نگهبان انتهایی به شریک زودمرحله‌ای تبدیل می‌کند و بازخورد سریع‌تر و کیفیت قابل‌اندازه‌گیری به‌همراه دارد.
#SoftwareTesting #FeaturePlanning #QualityEngineering #ShiftLeft #TestStrategy #QA #ProductDevelopment #Agile
🟣لینک مقاله:
https://cur.at/J1qOdPm?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
How to Contribute Meaningfully in Feature Planning
🟢 خلاصه مقاله:
**این مقاله نشان می‌دهد تسترها با طرح پرسش‌های هدفمند می‌توانند از ابتدای برنامه‌ریزی فیچر، ارزش بسازند. محورهای کلیدی شامل روشن‌کردن مسئله و مخاطب، معیارهای موفقیت و محدوده، و ثبت معیارهای پذیرش شفاف است. سپس باید ریسک‌ها و پوشش را زودهنگام آشکار کرد: مسیرهای خطا و لبه، یکپارچگی‌ها و جریان داده، و نیازهای غیرکارکردی مانند امنیت، حریم خصوصی، عملکرد، دسترس‌پذیری و بومی‌سازی. تمرکز بر تست‌پذیری نیز حیاتی است: مشاهده‌پذیری با لاگ و متریک، استراتژی اتوماسیون در لایه‌های مختلف، مدیریت داده آزمایشی و برابری محیط‌ها، و استفاده از feature flag، mock و sandbox برای交交交交交交. در نهایت، برنامه عرضه و یادگیری را تعریف کنید: rollout مرحله‌ای یا A/B، پایش و هشدار، و برنامه بازگشت. به‌گفته Mona M. Abd El-Rahman داشتن یک بانک پرسش آماده، تستر را از نگهبان انتهایی به شریک زودمرحله‌ای تبدیل می‌کند و بازخورد سریع‌تر و کیفیت قابل‌اندازه‌گیری به‌همراه دارد.
#SoftwareTesting #FeaturePlanning #QualityEngineering #ShiftLeft #TestStrategy #QA #ProductDevelopment #Agile
🟣لینک مقاله:
https://cur.at/J1qOdPm?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
🚀 How to Contribute Meaningfully in Feature Planning
Asking the Right Questions Early to Build Usable, Resilient, and Measurable Features
Forwarded from Bardia & Erfan
پاول دورُف: حاضرَم بمیرم، ولی آزادی و امنیت کاربران رو نفروشم!
در گفت‌وگوی عمیق با «لِکس فریدمن»، بنیان‌گذار تلگرام از فلسفهٔ زندگی، حریم خصوصی، بیت‌کوین و مقاومتش در برابر فشار دولت‌ها گفت.
> 🗣
🔒
او تأکید کرد تلگرام هیچوقت “در پشتی” برای دولت‌ها باز نکرده و در برابر فشار روسیه و ایران برای دسترسی به اطلاعات یا سانسور مقاومت کرده است.
>
📱 ۷ اصل فکری و مدیریتی پاول دورُف (بر اساس مصاحبه):
1️⃣ آزادی و اخلاق بالاتر از هر سود مالی — او می‌گوید حاضر است تمام دارایی‌اش را از دست بدهد تا آزادی بیان و امنیت کاربران حفظ شود.
2️⃣ مینیمالیسم و انضباط شخصی — سبک زندگی‌اش ساده، بدون الکل، قهوه یا حواس‌پرتی است؛ تمرکز کامل روی مأموریت و نظم ذهنی.
3️⃣ تیم کوچک، تأثیر بزرگ — معتقد است تیم‌های بزرگ بهره‌وری را می‌کُشند؛ موفقیت تلگرام حاصل اعتماد به چند نابغهٔ منضبط است.
4️⃣ مقاومت در برابر سانسور و در پشتی — هیچ دولت یا شرکتی حق کنترل یا شنود تلگرام را ندارد. رمزنگاری و طراحی MTProto را «دیوار آزادی دیجیتال» می‌نامد.
5️⃣ پول و قدرت ابزارند، نه هدف — او از مدل‌های انحصاری و کمیسیون‌های اپل و گوگل انتقاد می‌کند و تأکید دارد که ثروت نباید آزادی را محدود کند.
6️⃣ باور به فناوری آزاد مثل بیت‌کوین — بیت‌کوین را «نمادِ کاهش نیاز به اعتماد به واسطه‌ها و آزادی مالی» می‌داند؛ از پروژه TON به‌عنوان زیربنای اقتصاد آزاد تلگرام یاد می‌کند.
7️⃣ نگاه فلسفی به زندگی و مرگ — از کافکا، شوپنهاور و «جاودانگی کوانتومی» می‌گوید؛ باور دارد انسان باید بدون ترس از مرگ، بر پایهٔ ارزش‌های خودش زندگی کند.
در گفت‌وگوی عمیق با «لِکس فریدمن»، بنیان‌گذار تلگرام از فلسفهٔ زندگی، حریم خصوصی، بیت‌کوین و مقاومتش در برابر فشار دولت‌ها گفت.
> 🗣
«من ترجیح می‌دم بمیرم و تمام داراییم رو از دست بدهم تا اینکه اطلاعات کاربران رو به هر دولتی تحویل بدم.
آزادی و امنیت داده‌ها، خط قرمز من و تلگرامه.»
🔒
او تأکید کرد تلگرام هیچوقت “در پشتی” برای دولت‌ها باز نکرده و در برابر فشار روسیه و ایران برای دسترسی به اطلاعات یا سانسور مقاومت کرده است.
>
«در روسیه و ایران بارها تلاش شد ما رو مجبور به همکاری کنن. ولی ما مقاومت کردیم چون اگر یک‌بار کوتاه بیای، دیگه آزادی واقعی وجود نداره.»
📱 ۷ اصل فکری و مدیریتی پاول دورُف (بر اساس مصاحبه):
1️⃣ آزادی و اخلاق بالاتر از هر سود مالی — او می‌گوید حاضر است تمام دارایی‌اش را از دست بدهد تا آزادی بیان و امنیت کاربران حفظ شود.
2️⃣ مینیمالیسم و انضباط شخصی — سبک زندگی‌اش ساده، بدون الکل، قهوه یا حواس‌پرتی است؛ تمرکز کامل روی مأموریت و نظم ذهنی.
3️⃣ تیم کوچک، تأثیر بزرگ — معتقد است تیم‌های بزرگ بهره‌وری را می‌کُشند؛ موفقیت تلگرام حاصل اعتماد به چند نابغهٔ منضبط است.
4️⃣ مقاومت در برابر سانسور و در پشتی — هیچ دولت یا شرکتی حق کنترل یا شنود تلگرام را ندارد. رمزنگاری و طراحی MTProto را «دیوار آزادی دیجیتال» می‌نامد.
5️⃣ پول و قدرت ابزارند، نه هدف — او از مدل‌های انحصاری و کمیسیون‌های اپل و گوگل انتقاد می‌کند و تأکید دارد که ثروت نباید آزادی را محدود کند.
6️⃣ باور به فناوری آزاد مثل بیت‌کوین — بیت‌کوین را «نمادِ کاهش نیاز به اعتماد به واسطه‌ها و آزادی مالی» می‌داند؛ از پروژه TON به‌عنوان زیربنای اقتصاد آزاد تلگرام یاد می‌کند.
7️⃣ نگاه فلسفی به زندگی و مرگ — از کافکا، شوپنهاور و «جاودانگی کوانتومی» می‌گوید؛ باور دارد انسان باید بدون ترس از مرگ، بر پایهٔ ارزش‌های خودش زندگی کند.
کامپایلرهای درجا (JIT Compilers) در JVM چگونه پرفورمنس برنامه‌ها را بهبود می‌دهند؟
می‌دونیم که برنامه‌های نوشته شده با جاوا، ابتدا به بایت‌کد (bytecode) کامپایل میشن و JVM بایت‌کدها رو به‌صورت مفسری اجرا میکنه. این فرآیند نسبت به این که کدهای جاوا مستقیم به زبان ماشین کامپایل و اجرا بشن کندتره اما وجود همین مکانیزمه که جاوا رو کراس‌پلتفرم میکنه.
برای حل این مساله، دو کامپایلر درجا به نام‌های C1 و C2 در JVM وجود دارن. وظیفه این کامپایلرها به‌طور خلاصه اینه که قسمت‌هایی از برنامه که بیشتر از میزان مشخصی اجرا میشن (اصطلاحا نقاط داغ) رو به زبان ماشین کامپایل میکنن تا اون قسمت‌ها دیگه به‌صورت مفسری اجرا نشن. کدهای ماشینی که این کامپایلرها تولید میکنن در محلی از حافظه به نام Code Cache ذخیره میشه.
واحد کامپایل برای کامپایلرهای درجا، متده. تعداد دفعاتی که یه متد اجرا میشه توسط JVM ذخیره میشه و وقتی این تعداد از میزان مشخصی بالاتر بره، کامپایلرهای درجا وارد عمل میشن.
نحوه عملکرد این دو کامپایلر به‌طور خلاصه به این صورته:
۱- متد به‌صورت پیش‌فرض، مفسری اجرا میشه.
۲- وقتی تعداد دفعات اجرای متد از مقدار خاصی بیشتر بشه، کامپایلر C1 اون متد رو به زبان ماشین کامپایل میکنه. همچنین C1 دستورهایی رو در متد کامپایل شده قرار میده تا اطلاعاتی رو درباره جزئیات عملکرد متد در طول اجرای برنامه جمع‌آوری کنن (پروفایلینگ). این اطلاعات بعدا توسط C2 استفاده میشن.
۳- اگر متد همچنان زیاد اجرا بشه یعنی واقعا متد پرکاربرد و اصطلاحا داغیه. اینجا C2 وارد عمل میشه و متد رو دوباره به کد ماشین کامپایل میکنه. اما این بار C2 از اطلاعاتی که از اجرای متد در طول برنامه جمع‌آوری شده (با استفاده از دستورایی که C1 به متد اضافه کرده بود) استفاده میکنه و با این اطلاعات میتونه بهینه‌ترین و سریع‌ترین کد ماشین ممکن رو تولید کنه.
پس ممکنه متدی که کم اجرا میشه هیچوقت به کد ماشین کامپایل نشه. یا متدی با C1 کامپایل بشه اما به اندازه‌ای زیاد اجرا نشه که C2 کامپایلش کنه. این که دقیقا بعد از چندبار اجرای یه متد این دوتا کامپایلر وارد عمل بشن قابل تنظیمه اما مقادیر پیش‌فرضی که دارن احتمالا برای اکثر برنامه‌ها مناسبه و نیازی به تغییرشون نیست.
<Mostafa Nasiri/>
می‌دونیم که برنامه‌های نوشته شده با جاوا، ابتدا به بایت‌کد (bytecode) کامپایل میشن و JVM بایت‌کدها رو به‌صورت مفسری اجرا میکنه. این فرآیند نسبت به این که کدهای جاوا مستقیم به زبان ماشین کامپایل و اجرا بشن کندتره اما وجود همین مکانیزمه که جاوا رو کراس‌پلتفرم میکنه.
برای حل این مساله، دو کامپایلر درجا به نام‌های C1 و C2 در JVM وجود دارن. وظیفه این کامپایلرها به‌طور خلاصه اینه که قسمت‌هایی از برنامه که بیشتر از میزان مشخصی اجرا میشن (اصطلاحا نقاط داغ) رو به زبان ماشین کامپایل میکنن تا اون قسمت‌ها دیگه به‌صورت مفسری اجرا نشن. کدهای ماشینی که این کامپایلرها تولید میکنن در محلی از حافظه به نام Code Cache ذخیره میشه.
واحد کامپایل برای کامپایلرهای درجا، متده. تعداد دفعاتی که یه متد اجرا میشه توسط JVM ذخیره میشه و وقتی این تعداد از میزان مشخصی بالاتر بره، کامپایلرهای درجا وارد عمل میشن.
نحوه عملکرد این دو کامپایلر به‌طور خلاصه به این صورته:
۱- متد به‌صورت پیش‌فرض، مفسری اجرا میشه.
۲- وقتی تعداد دفعات اجرای متد از مقدار خاصی بیشتر بشه، کامپایلر C1 اون متد رو به زبان ماشین کامپایل میکنه. همچنین C1 دستورهایی رو در متد کامپایل شده قرار میده تا اطلاعاتی رو درباره جزئیات عملکرد متد در طول اجرای برنامه جمع‌آوری کنن (پروفایلینگ). این اطلاعات بعدا توسط C2 استفاده میشن.
۳- اگر متد همچنان زیاد اجرا بشه یعنی واقعا متد پرکاربرد و اصطلاحا داغیه. اینجا C2 وارد عمل میشه و متد رو دوباره به کد ماشین کامپایل میکنه. اما این بار C2 از اطلاعاتی که از اجرای متد در طول برنامه جمع‌آوری شده (با استفاده از دستورایی که C1 به متد اضافه کرده بود) استفاده میکنه و با این اطلاعات میتونه بهینه‌ترین و سریع‌ترین کد ماشین ممکن رو تولید کنه.
پس ممکنه متدی که کم اجرا میشه هیچوقت به کد ماشین کامپایل نشه. یا متدی با C1 کامپایل بشه اما به اندازه‌ای زیاد اجرا نشه که C2 کامپایلش کنه. این که دقیقا بعد از چندبار اجرای یه متد این دوتا کامپایلر وارد عمل بشن قابل تنظیمه اما مقادیر پیش‌فرضی که دارن احتمالا برای اکثر برنامه‌ها مناسبه و نیازی به تغییرشون نیست.
<Mostafa Nasiri/>
❤3
🔵 عنوان مقاله
What does successful automation look like to you? Have you ever seen it?
🟢 خلاصه مقاله:
اتوماسیون موفق در شرکت‌های مختلف شکل‌های متفاوتی دارد، اما نقطه مشترک آن نتایج تجاری ملموس و اعتماد تیم است: چرخه انتشار سریع‌تر، خطاهای فراری کمتر، و شکست‌های معنادار به‌جای نویز. تجربه‌های مطرح‌شده در Reddit بر چند اصل تاکید دارند: پایداری و سرعت در CI/CD، هرم تست با تمرکز بر unit و integration و تعداد اندک E2E برای مسیرهای حیاتی، کد تست قابل نگهداری و مدیریت داده/محیط قابل اتکا. مالکیت مشترک بین Dev و QA، معیارهای روشن، و قابلیت مشاهده‌پذیری (لاگ، اسکرین‌شات، ترِیس و ردیابی flaky) ضروری‌اند. موفقیت یعنی ROI واقعی: زمان آزادشده برای بهبود محصول، کاهش hotfix، و اطمینان در هر PR—و دوری از ضدالگوهایی مثل افراط در UI tests یا تعقیب پوشش ۱۰۰٪.
#TestAutomation #SoftwareTesting #QA #DevOps #CICD #AutomationStrategy #QualityEngineering
🟣لینک مقاله:
https://cur.at/w3kN7Xu?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
What does successful automation look like to you? Have you ever seen it?
🟢 خلاصه مقاله:
اتوماسیون موفق در شرکت‌های مختلف شکل‌های متفاوتی دارد، اما نقطه مشترک آن نتایج تجاری ملموس و اعتماد تیم است: چرخه انتشار سریع‌تر، خطاهای فراری کمتر، و شکست‌های معنادار به‌جای نویز. تجربه‌های مطرح‌شده در Reddit بر چند اصل تاکید دارند: پایداری و سرعت در CI/CD، هرم تست با تمرکز بر unit و integration و تعداد اندک E2E برای مسیرهای حیاتی، کد تست قابل نگهداری و مدیریت داده/محیط قابل اتکا. مالکیت مشترک بین Dev و QA، معیارهای روشن، و قابلیت مشاهده‌پذیری (لاگ، اسکرین‌شات، ترِیس و ردیابی flaky) ضروری‌اند. موفقیت یعنی ROI واقعی: زمان آزادشده برای بهبود محصول، کاهش hotfix، و اطمینان در هر PR—و دوری از ضدالگوهایی مثل افراط در UI tests یا تعقیب پوشش ۱۰۰٪.
#TestAutomation #SoftwareTesting #QA #DevOps #CICD #AutomationStrategy #QualityEngineering
🟣لینک مقاله:
https://cur.at/w3kN7Xu?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Reddit
From the softwaretesting community on Reddit
Explore this post and more from the softwaretesting community