Software Engineer Labdon
625 subscribers
43 photos
4 videos
2 files
807 links
👑 Software Labdon

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

ادمین:
@mrbardia72
Download Telegram
🔵 عنوان مقاله
Understanding Playwright Agents

🟢 خلاصه مقاله:
**عرضه اخیر Playwright Agents یک گام مهم در خودکارسازی آزمون‌های مرورگری است: به‌جای نوشتن تک‌تک گام‌ها، هدف را توصیف می‌کنید و عامل‌ها با برنامه‌ریزی، اجرا و پایش تکرارشونده، مسیر رسیدن به آن هدف را در مرورگرهای واقعی پیدا می‌کنند. این رویکرد با تکیه بر نقاط قوت Playwright—پوشش چندمرورگری، ابزارهای رهگیری و انتخاب‌گرهای پایدار—زمان ساخت تست را کاهش می‌دهد و نگه‌داری را آسان‌تر می‌کند. معماری هسته شامل سه بخش برنامه‌ریز، اجراکننده و ناظر است که با ترکیب منطق قطعی و استدلال مدل‌محور تلاش می‌کند هم انعطاف‌پذیر باشد و هم قابلیت بازپخش و مشاهده‌پذیری را حفظ کند. Sławomir Radzymiński در یک بررسی عمیق، نحوه کار داخلی این عامل‌ها، الگوی حلقه تصمیم‌گیری، ساخت مدل از DOM و مثال‌های عملی (ورود، پرداخت، و پایدارسازی سناریوهای شکننده) را توضیح می‌دهد و در کنار آن، محدودیت‌ها و بهترین‌روش‌ها را نیز بیان می‌کند: تعریف هدف شفاف، استفاده از data-testid پایدار، محدود کردن عمق اکتشاف، و پین‌کردن محیط در CI. مسیر پیشنهادی پذیرش نیز استفاده از Agent برای اکتشاف و تولید تست‌های اولیه و سپس تثبیت آن‌ها به اسکریپت‌های قطعی Playwright است.

#Playwright #PlaywrightAgents #E2ETesting #BrowserAutomation #TestAutomation #LLM #QA #DevTools

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


👑 @software_Labdon
🔵 عنوان مقاله
Improved BRICKSTORM YARA Rules (GitHub Repo)

🟢 خلاصه مقاله:
به‌روزرسانی تازه‌ای از سوی Florian Roth بر پایه گزارش Google درباره بدافزار BRICKSTORM منتشر شده که مجموعه قوانین YARA را در یک مخزن GitHub به‌طور شفاف‌تر، سریع‌تر و قابل اتکاتر می‌کند. او با حذف regexهای غیرضروری، کاهش خطای مثبت و بهبود کارایی اسکن را هدف گرفته و با شفاف‌سازی encoding رشته‌ها و توالی‌های بایتی، از رفتار یکسان قوانین در حالت‌های مختلف اطمینان داده است. همچنین با ساده‌سازی و یکپارچه‌سازی قواعد، نگهداشت و فهم آن‌ها آسان‌تر شده است. افزوده‌شدن metadata شامل ارجاع به گزارش Google، اطلاعات نویسنده و نسخه، شفافیت و قابلیت پیگیری را افزایش می‌دهد و استقرار و بهبود مستمر قوانین را برای تیم‌های دفاعی ساده‌تر می‌کند.

#YARA #BRICKSTORM #MalwareDetection #ThreatIntel #Google #FlorianRoth #CyberSecurity #GitHub

🟣لینک مقاله:
https://github.com/Neo23x0/signature-base/blob/master/yara/apt_cn_brickstorm_sep25.yar?utm_source=tldrinfosec


👑 @software_Labdon
🔵 عنوان مقاله
Debugging Mobile Web Apps Shouldn't Be This Hard, So I Built a Logger

🟢 خلاصه مقاله:
به‌گفته‌ی Nishant Bhandari، دیباگ اپلیکیشن‌های وب موبایل بیش از حد دشوار شده است؛ ابزارهای دسکتاپ و ریموت همیشه شرایط واقعی دستگاه را نشان نمی‌دهند. او برای ساده‌سازی این روند، ابزار متن‌باز interactive-logger را معرفی می‌کند؛ ابزاری سبک که با افزودن یک قطعه کوچک، لاگ‌ها و خطاها را همان‌جا روی دستگاه و به‌صورت لحظه‌ای نمایش می‌دهد تا بازتولید و اشتراک‌گذاری باگ‌ها سریع‌تر و دقیق‌تر انجام شود. تمرکز این راهکار روی سادگی و کارکرد در سناریوهای رایج وب موبایل (مانند PWA و WebView) و بدون وابستگی به فریم‌ورک است.

#MobileWeb #Debugging #DevTools #OpenSource #Logging #WebDev #JavaScript #Frontend

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


👑 @software_Labdon
🔵 عنوان مقاله
Google Sues to Disrupt Chinese SMS Phishing Triad (2 minute read)

🟢 خلاصه مقاله:
Google در دادگاه Southern District of New York علیه ۲۵ نفر مرتبط با ابزار چینی Lighthouse شکایت کرده است؛ ابزاری از نوع phishing-as-a-service که با پیامک‌های جعلی به نام USPS، اپراتورهای عوارض جاده‌ای، پلتفرم‌های تجارت الکترونیک و مؤسسات مالی، بیش از یک میلیون قربانی را در ۱۲۰ کشور هدف قرار داده است. این شبکه با هدایت کاربران به وب‌سایت‌های موبایلی جعلی، داده‌های کارت پرداخت را جمع‌آوری می‌کند و سپس با سوءاستفاده از فرایندهای ثبت‌نام قانونی Apple Pay و Google Pay، از طریق فریب کاربران برای ارائه کدهای یکبارمصرف، کارت‌های سرقت‌شده را به کیف‌پول‌های موبایلی متصل می‌سازد. هدف شکایت، مختل‌کردن زیرساخت این عملیات و بازدارندگی از الگوهای مشابه در مقیاس جهانی است.

#Cybersecurity #Phishing #SMSPhishing #Google #ApplePay #GooglePay #PhaaS #Fraud

🟣لینک مقاله:
https://krebsonsecurity.com/2025/11/google-sues-to-disrupt-chinese-sms-phishing-triad/?utm_source=tldrinfosec


👑 @software_Labdon
🔵 عنوان مقاله
Vulnerability in Dolby Decoder Can Allow Zero-Click Attacks (2 minute read)

🟢 خلاصه مقاله:
پژوهشگران Google's Project Zero یک آسیب‌پذیری ناشی از buffer overflow را در Dolby's Unified Decoder پیدا کرده‌اند؛ مولفه‌ای که در Android برای decode کردن محلی تمام پیام‌ها و پیوست‌های صوتی به‌کار می‌رود. این نقص می‌تواند به remote code execution منجر شود و به‌دلیل اجرای خودکار فرآیند decode در مسیر رسانه‌ای سیستم، امکان حملات zero-click را فراهم می‌کند؛ بدون اینکه کاربر کاری انجام دهد. از آنجا که بسیاری از اپ‌ها در Android برای پردازش‌های پس‌زمینه (مثل پیش‌نمایش یا استخراج اطلاعات صوتی) به همین decoder تکیه می‌کنند، سطح حمله گسترده است. توصیه می‌شود به‌محض انتشار، به‌روزرسانی‌های امنیتی Android و سازندگان دستگاه اعمال شود و از سخت‌سازی مسیرهای رسانه‌ای، sandboxing و شیوه‌های ایمن حافظه استفاده شود.

#Android #Security #Vulnerability #ZeroClick #RCE #Dolby #ProjectZero #Cybersecurity

🟣لینک مقاله:
https://www.securityweek.com/vulnerability-in-dolby-decoder-can-allow-zero-click-attacks/?utm_source=tldrinfosec


👑 @software_Labdon
👍1
🔵 عنوان مقاله
How I Automated Test Scope Analysis with a CLI Tool

🟢 خلاصه مقاله:
** Josphine Job روند ساخت یک ابزار CLI با Node.js را توضیح می‌دهد که با استفاده از GitHub API تغییرات کد را به‌سرعت تحلیل می‌کند و پیشنهادهای هوشمند برای محدودهٔ تست ارائه می‌دهد. این ابزار با دریافت اطلاعات PR و commitها، فایل‌های تغییرکرده را بررسی و وابستگی‌ها را تحلیل می‌کند و سپس با لایهٔ هوش مصنوعی، سناریوهای تست اولویت‌دار (از واحد تا یکپارچه) پیشنهاد می‌دهد. خروجی می‌تواند در ترمینال، به‌صورت Markdown/JSON، یا به‌عنوان کامنت CI روی PR نمایش داده شود. ملاحظاتی مانند کش‌کردن، رعایت حریم خصوصی، و fallback آفلاین در نظر گرفته شده و هدف، کوتاه‌کردن چرخهٔ بازخورد و افزایش پوشش و اعتماد به تغییرات کد است.

#TestAutomation #CLI #NodeJS #GitHubAPI #AIinTesting #DevTools #CICD #SoftwareQuality

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


👑 @software_Labdon
Forwarded from Linux Labdon
کاهش هزینه سیستم‌های هوش مصنوعی با Semantic Caching

با رشد مدل‌های زبانی بزرگ و پیشرفته، هزینه و زمان پاسخ‌دهی هم به شدت افزایش پیدا کرده. مدل‌هایی مثل GPT-5 یا Claude برای کارهای پیچیده فوق‌العاده‌اند، ولی استفاده از اون‌ها هم پرهزینه و هم کند محسوب می‌شه. از طرف دیگه، AI Agentها واقعاً «توکن‌خور» هستن؛ یعنی برای انجام یک کار معمولاً چندین مرحله طی می‌کنن: تحقیق، برنامه‌ریزی، عمل و بازتاب و تکرار. همین باعث می‌شه چندین بار با مدل تماس بگیرن و در نتیجه هزینه و تأخیر افزایش پیدا کنه و متن‌های طولانی‌تر تولید بشه. برای مثال، یه بنچمارک اخیر از TheAgentCompany در ۲۰۲۵ نشون داده اجرای کامل یک Agent گاهی تا ۶.۸ دلار هزینه داره.

یکی از مشکلات اصلی در دنیای واقعی، تکراری بودن سوال‌هاست، مخصوصاً توی پشتیبانی مشتری. کاربران دائماً سوال‌های مشابهی می‌پرسن: مثل «چطور پولم رو پس بگیرم؟» یا «شرایط بازگشت وجه چیه؟» و Agent مجبور می‌شه هر بار پاسخ رو از صفر تولید کنه. نتیجه‌ش افزایش هزینه، طولانی شدن زمان پاسخ و فشار بیشتر روی سیستم‌های RAG و زیرساخت‌هاست.

در نگاه اول، ممکنه فکر کنیم کش کلاسیک کفایت می‌کنه. ایده‌ی کش ساده اینه که اگر یک سوال قبلاً پاسخ داده شده، دوباره سراغ مدل نریم. ولی مشکل اینجاست که کش سنتی دنبال Exact Match یا تطابق دقیق متنه. سوال‌هایی که از نظر معنی یکی هستن ولی عبارت‌هاشون فرق می‌کنه، مثل: «می‌خوام پولم رو پس بگیرم»، «چطور می‌تونم درخواست بازگشت وجه بدم؟» و «سیاست بازگشت پولتون چیه؟»، همه Cache Miss می‌شن و کش عملاً استفاده نمی‌شه.

اینجاست که Semantic Caching وارد می‌شه. به جای تطابق کلمه‌به‌کلمه، کش به معنی و مفهوم جمله نگاه می‌کنه. مزیت اصلی‌ش اینه که Recall و Hit Rate بالاتره و احتمال استفاده از کش و صرفه‌جویی خیلی بیشتر می‌شه. البته چالشش هم اینه که گاهی ممکنه جواب بی‌ربط بده یا همون «False Positive» رخ بده.

روش کار Semantic Caching ساده است ولی هوشمندانه: ابتدا سوال کاربر به Embedding یا بردار عددی تبدیل می‌شه. بعد با بردارهای موجود در کش با Semantic Search مقایسه می‌شه. اگر فاصله معنایی کم باشه، پاسخ از کش برگردونده می‌شه؛ در غیر این صورت به RAG یا LLM می‌ریم. در نهایت سوال و پاسخ جدید هم ذخیره می‌شه تا دفعه بعدی قابل استفاده باشه.

پیاده‌سازی Semantic Caching با چالش‌هایی همراهه؛ مثل دقت (Accuracy) که آیا کش جواب درست می‌ده، کارایی (Performance) و میزان Cache Hit، سرعت سرویس‌دهی، آپدیت‌پذیری کش و اینکه آیا می‌تونیم کش رو گرم، تازه‌سازی یا پاکسازی کنیم. همچنین مشاهده‌پذیری (Observability) مهمه تا بتونیم hit rate، latency، صرفه‌جویی هزینه و کیفیت کش رو بسنجیم.

معیارهای اصلی سنجش کش شامل Cache Hit Rate هست که نشون می‌ده چند درصد درخواست‌ها از کش پاسخ داده می‌شن و Precision/Recall/F1 Score که کیفیت و دقت پاسخ‌ها رو مشخص می‌کنه. برای بهبود دقت و کارایی کش هم می‌تونیم Threshold فاصله رو تنظیم کنیم، Reranker اضافه کنیم مثل Cross-encoder یا LLM-as-a-judge، از Fuzzy Matching برای تایپوها استفاده کنیم و فیلترهای اضافی مثل تشخیص پرسش‌های زمان‌محور (Temporal) یا تشخیص کد (Python، Java و…) اعمال کنیم تا سوالات اشتباه وارد کش نشن.

یه مثال واقعی از این تکنولوژی پروژه waLLMartCache در Walmart هست. اون‌ها با نوآوری‌هایی مثل Load Balancer برای توزیع کش روی چند Node و Dual-tiered Storage که L1 = Vector DB و L2 = In-memory Cache مثل Redis هست، هم سرعت و هم دقت رو بالا بردن. Multi-tenancy هم باعث شده چند تیم یا اپلیکیشن از یک زیرساخت مشترک استفاده کنن. Decision Engine هم شامل تشخیص کد و زمانه و اگر سوال مناسب کش نباشه مستقیماً به LLM یا RAG می‌ره. نتیجه‌ش رسیدن به دقت نزدیک ۹۰٪ بوده.

<Reza Jafari/>

👉 https://t.iss.one/addlist/AJ7rh2IzIh02NTI0
2
🔵 عنوان مقاله
Seriously Testing LLMs

🟢 خلاصه مقاله:
این مقاله به این می‌پردازد که برای آزمون جدی LLMs چه نیاز است. نویسنده با تکیه بر مجموعه‌ای از آزمایش‌ها، نشان می‌دهد چرا اتکا به دمو یا امتیازهای سطحی کافی نیست و چگونه رفتار مدل با تغییر متن راهنما، زمینه و زمان تغییر می‌کند. James Bach در این مسیر روش LARC را معرفی می‌کند؛ رویکردی ساخت‌یافته و اکتشافی برای برنامه‌ریزی، اجرای آزمون‌ها و تفسیر نتایج که بر طراحی موارد تنشی و خصمانه، مشاهده نظام‌مند و بهبود تکرارشونده تأکید دارد تا الگوهای خطا و محدودیت‌های قابلیت اعتماد آشکار شوند. مقاله توضیح می‌دهد که چرا آزمون جامع دشوار و پرهزینه است: خروجی‌های غیرقطعی، نبود داور قطعی برای «درستی»، حساسیت به Prompt و زمینه، به‌روزرسانی‌های مدل که بازتولیدپذیری را می‌شکنند، محدودیت معیارهای کمی، و نیاز به ابزار، داده، محاسبات و داوری انسانی. در نهایت پیشنهاد می‌شود آزمون LLM را یک کار تحقیقاتی-حرفه‌ای ببینیم: اهداف و ریسک‌ها را روشن کنیم، داده‌های متنوع و خصمانه بسازیم، ثبت و رهگیری کامل انجام دهیم، و با اجرای تکرارشونده روش LARC میان عمق و وسعت، خودکارسازی و قضاوت کارشناسی، و هزینه و کفایت تصمیم‌گیری کنیم.

#LLMs #SoftwareTesting #AIQuality #Evaluation #PromptEngineering #Reliability #JamesBach #MachineLearning

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


👑 @software_Labdon
👍1
🔵 عنوان مقاله
Spotter (GitHub Repo)

🟢 خلاصه مقاله:
Spotter یک اسکنر امنیتی متن‌باز در GitHub است که با تکیه بر قوانین مبتنی بر CEL، تنظیمات ناایمن و خطاهای پیکربندی را در خوشه‌های Kubernetes شناسایی می‌کند. این ابزار می‌تواند انواع منابع Kubernetes را بررسی کند، قواعد سفارشی‌سازی‌شده را برای استانداردهای داخلی پشتیبانی کند و هم روی خوشه‌های اجراشده و هم پیش از استقرار (در CI/CD یا GitOps) به کار رود. رویکرد policy-as-code آن، کشف سریع و قابل‌اقدام مسائل امنیتی و اجرای یکپارچه سیاست‌ها را ممکن می‌سازد؛ هرچند جایگزین لایه‌های دیگر مانند پایش در زمان اجرا یا اسکن تصاویر نیست و مکمل آن‌هاست.

#Kubernetes #Security #CEL #DevSecOps #CloudNative #OpenSource #PolicyAsCode #SecurityScanning

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


👑 @software_Labdon
🔵 عنوان مقاله
AI in Testing: Hype or Real Progress?

🟢 خلاصه مقاله:
این یادداشت با نگاهی عمل‌گرایانه، دیدگاه Arik Aharoni را درباره نقش واقعی هوش مصنوعی در تست نرم‌افزار شرح می‌دهد: او نشان می‌دهد کجاها AI ارزش ملموس ایجاد کرده و کجاها همچنان اغراق می‌شود. به‌گفته او، AI در تولید اولیه تست‌ها از نیازمندی‌ها، پیشنهاد موارد مرزی، کاهش شکنندگی تست‌های UI، شناسایی تست‌های flaky، خوشه‌بندی خطاها، اولویت‌بندی ریسک‌محور و ساخت داده‌های آزمایشی مفید است؛ همچنین در بررسی‌های بصری و دسترس‌پذیری می‌تواند رگرسیون‌های ظریف را آشکار کند.

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

جمع‌بندی Aharoni این است: پیشروی واقعی اما تدریجی است. با اجرای آزمایشی کوچک، معیارهای روشن (مانند نرخ کشف عیب و پایداری تست) و جریان‌های human-in-the-loop، می‌توان از AI در حوزه‌هایی با سیگنال قوی—مثل نگهداشت و تریاژ شکست‌ها—بهره برد؛ AI باید مکمل مهارت تیم‌های QA و مهندسی باشد، نه جایگزین آن.

#AIinTesting #SoftwareTesting #QA #TestAutomation #QualityEngineering #LLM #DevOps #TestStrategy

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


👑 @software_Labdon