Rust vs. Python: Finding the right balance between speed and simplicity
https://blog.jetbrains.com/rust/2025/11/10/rust-vs-python-finding-the-right-balance-between-speed-and-simplicity/
https://blog.jetbrains.com/rust/2025/11/10/rust-vs-python-finding-the-right-balance-between-speed-and-simplicity/
The JetBrains Blog
Rust vs. Python: Finding the right balance between speed and simplicity | The RustRover Blog
Compare Rust and Python across performance, usability, tooling, and ecosystem. Learn which language is best for your next project.
🔵 عنوان مقاله
Determinism is Overrated
🟢 خلاصه مقاله:
Determinism is Overrated یادآور می‌شود که توسعه و آزمون اپلیکیشن‌های AI با نرم‌افزارهای سنتی فرق دارد، چون خروجی‌ها ذاتاً غیردترمینستیک‌اند. به‌جای تکیه بر تطابق دقیق رشته‌ای، باید کیفیت را در سطح توزیع نتایج سنجید: تعریف بازه‌های پذیرش، روبریک‌ها و امتیازدهی سازگار با هدف کاربر، و آزمون‌های سناریومحور. Jarad DeLorenzo پیشنهاد می‌کند در کنار تست‌های کاملاً دترمینستیک برای منطق اطراف مدل، از ابزارهای بازتولیدپذیری (نسخه‌بندی داده/پرومپت/مدل، ثبت seed و پارامترها) و ارزیابی احتمالاتی (آستانه‌های شباهت، top-k، چند seed) استفاده شود. در استقرار نیز A/B testing، canary، گاردریل‌ها، fallback و observability برای هزینه، تأخیر، درستی و ایمنی لازم است. پیام اصلی: به‌جای اجبار به خروجی‌های یکسان، برای نتایج قابل اتکا در دل تغییرپذیری طراحی کنید.
#AI #LLM #NonDeterminism #Testing #Evaluation #MLOps #AIBestPractices #SoftwareEngineering
🟣لینک مقاله:
https://cur.at/sfc6P6g?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Determinism is Overrated
🟢 خلاصه مقاله:
Determinism is Overrated یادآور می‌شود که توسعه و آزمون اپلیکیشن‌های AI با نرم‌افزارهای سنتی فرق دارد، چون خروجی‌ها ذاتاً غیردترمینستیک‌اند. به‌جای تکیه بر تطابق دقیق رشته‌ای، باید کیفیت را در سطح توزیع نتایج سنجید: تعریف بازه‌های پذیرش، روبریک‌ها و امتیازدهی سازگار با هدف کاربر، و آزمون‌های سناریومحور. Jarad DeLorenzo پیشنهاد می‌کند در کنار تست‌های کاملاً دترمینستیک برای منطق اطراف مدل، از ابزارهای بازتولیدپذیری (نسخه‌بندی داده/پرومپت/مدل، ثبت seed و پارامترها) و ارزیابی احتمالاتی (آستانه‌های شباهت، top-k، چند seed) استفاده شود. در استقرار نیز A/B testing، canary، گاردریل‌ها، fallback و observability برای هزینه، تأخیر، درستی و ایمنی لازم است. پیام اصلی: به‌جای اجبار به خروجی‌های یکسان، برای نتایج قابل اتکا در دل تغییرپذیری طراحی کنید.
#AI #LLM #NonDeterminism #Testing #Evaluation #MLOps #AIBestPractices #SoftwareEngineering
🟣لینک مقاله:
https://cur.at/sfc6P6g?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Medium
Determinism is Overrated
Why Your Best Engineers Can’t Build AI Systems
🔵 عنوان مقاله
Selenium tests breaking constantly after every UI change. Is test maintenance really supposed to take this much time?
🟢 خلاصه مقاله:
این مسئله مطرح شد که چرا تست‌های Selenium با هر تغییر در UI می‌شکنند و آیا این حجم از نگه‌داری طبیعی است یا نشانه‌ی مشکل در رویکرد. جامعه‌ی کاربری توصیه کرد وابستگی تست‌ها به جزئیات شکننده‌ی رابط را کم کنند (استفاده از data-test-id)، از الگوهایی مثل Page Object Model برای متمرکزکردن انتخاب‌گرها کمک بگیرند، و طبق Test Pyramid بیشتر پوشش را به لایه‌های Unit/API بدهند و فقط سناریوهای کاربرمحور کلیدی را با end‑to‑end اجرا کنند. برای کاهش test flakiness نیز بر waits مبتنی بر شرایط تجاری، کنترل وضعیت داده و محیط، اجتناب از تاخیرهای ثابت و انیمیشن‌ها، ایزوله‌سازی در CI، mock/stub کردن فراخوانی‌های ناپایدار، و قرنطینه و triage خودکار تست‌های flaky تأکید شد. جمع‌بندی این بود که نگه‌داری سنگین اغلب نتیجه‌ی استفاده‌ی بیش‌ازحد یا کوپلینگ شدید به UI است؛ با راهبردهای درست می‌توان automated tests پایدارتر و کم‌هزینه‌تر داشت.
#Selenium #TestAutomation #FlakyTests #UITesting #SoftwareTesting #QA #CICD #E2E
🟣لینک مقاله:
https://cur.at/Scyp8xS?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Selenium tests breaking constantly after every UI change. Is test maintenance really supposed to take this much time?
🟢 خلاصه مقاله:
این مسئله مطرح شد که چرا تست‌های Selenium با هر تغییر در UI می‌شکنند و آیا این حجم از نگه‌داری طبیعی است یا نشانه‌ی مشکل در رویکرد. جامعه‌ی کاربری توصیه کرد وابستگی تست‌ها به جزئیات شکننده‌ی رابط را کم کنند (استفاده از data-test-id)، از الگوهایی مثل Page Object Model برای متمرکزکردن انتخاب‌گرها کمک بگیرند، و طبق Test Pyramid بیشتر پوشش را به لایه‌های Unit/API بدهند و فقط سناریوهای کاربرمحور کلیدی را با end‑to‑end اجرا کنند. برای کاهش test flakiness نیز بر waits مبتنی بر شرایط تجاری، کنترل وضعیت داده و محیط، اجتناب از تاخیرهای ثابت و انیمیشن‌ها، ایزوله‌سازی در CI، mock/stub کردن فراخوانی‌های ناپایدار، و قرنطینه و triage خودکار تست‌های flaky تأکید شد. جمع‌بندی این بود که نگه‌داری سنگین اغلب نتیجه‌ی استفاده‌ی بیش‌ازحد یا کوپلینگ شدید به UI است؛ با راهبردهای درست می‌توان automated tests پایدارتر و کم‌هزینه‌تر داشت.
#Selenium #TestAutomation #FlakyTests #UITesting #SoftwareTesting #QA #CICD #E2E
🟣لینک مقاله:
https://cur.at/Scyp8xS?m=web
➖➖➖➖➖➖➖➖
👑 @software_Labdon
Reddit
From the QualityAssurance community on Reddit
Explore this post and more from the QualityAssurance community