Software Engineer Labdon
609 subscribers
43 photos
4 videos
2 files
763 links
👑 Software Labdon

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

ادمین:
@mrbardia72
Download Telegram
🔵 عنوان مقاله
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
🔵 عنوان مقاله
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
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
🔵 عنوان مقاله
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
🔵 عنوان مقاله
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
1
این کتاب خیلی ساده و روان توضیح میده چرا Rust اینقدر سر و صدا کرده و چرا خیلی‌ها دارن سمتش میرن:

نشون میده چطوری با سیستم 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
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
🤡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
کامپیوترها برای نگهداری و نمایش کاراکترهای یک متن از یه فضای یک بایتی (معادل هشت بیت 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/>
👍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
Forwarded from Bardia & Erfan
پاول دورُف: حاضرَم بمیرم، ولی آزادی و امنیت کاربران رو نفروشم!

در گفت‌وگوی عمیق با «لِکس فریدمن»، بنیان‌گذار تلگرام از فلسفهٔ زندگی، حریم خصوصی، بیت‌کوین و مقاومتش در برابر فشار دولت‌ها گفت.
> 🗣
«من ترجیح می‌دم بمیرم و تمام داراییم رو از دست بدهم تا اینکه اطلاعات کاربران رو به هر دولتی تحویل بدم.
آزادی و امنیت داده‌ها، خط قرمز من و تلگرامه.»

🔒

او تأکید کرد تلگرام هیچ‌وقت “در پشتی” برای دولت‌ها باز نکرده و در برابر فشار روسیه و ایران برای دسترسی به اطلاعات یا سانسور مقاومت کرده است.
>
«در روسیه و ایران بارها تلاش شد ما رو مجبور به همکاری کنن. ولی ما مقاومت کردیم چون اگر یک‌بار کوتاه بیای، دیگه آزادی واقعی وجود نداره.»



📱 ۷ اصل فکری و مدیریتی پاول دورُف (بر اساس مصاحبه):

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/>
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
🔵 عنوان مقاله
Apple patches critical zero-day in ImageIO amid reports of targeted exploits (2 minute read)

🟢 خلاصه مقاله:
اپل یک آسیب‌پذیری بحرانی از نوع zero-day با شناسه CVE-2025-43300 را در چارچوب ImageIO برطرف کرد؛ نقص «out-of-bounds write» می‌تواند هنگام پردازش تصاویر مخرب باعث خرابی حافظه و در سناریوهای بدتر اجرای کد شود. بنا بر گزارش‌ها، این آسیب‌پذیری در حملات بسیار پیشرفته و هدفمند علیه افراد خاص مورداستفاده قرار گرفته است. به‌روزرسانی‌ها برای iOS، iPadOS و macOS—including older devices—منتشر شده و تعداد zero-dayهای فعالاً بهره‌برداری‌شده که اپل در سال 2025 رفع کرده را به هفت مورد رسانده است. توصیه می‌شود کاربران فوراً دستگاه‌های خود را به‌روزرسانی و به‌روزرسانی خودکار را فعال کنند.

#Apple #ImageIO #CVE-2025-43300 #ZeroDay #iOS #iPadOS #macOS #Cybersecurity

🟣لینک مقاله:
https://www.csoonline.com/article/4058589/apple-patches-critical-zero-day-in-imageio-amid-reports-of-targeted-exploits.html?utm_source=tldrinfosec


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

🟢 خلاصه مقاله:
** این GitHub Repo راه‌اندازی Windows داخل یک محیط Docker را ساده می‌کند: با دانلود خودکار ISO و بهره‌گیری از شتاب‌دهی KVM، یک ماشین مجازی Windows با کارایی نزدیک به بومی اجرا می‌شود. هدف، ارائه محیطی تکرارپذیر، قابل‌حمل و یک‌بارمصرف برای توسعه و تست است؛ با امکان دسترسی از راه دور (مثلاً RDP/VNC) و نگه‌داری داده‌ها از طریق volumeها. این راه‌حل برای CI/CD، تست میان‌سکویی و اجرای ابزارهای مخصوص Windows مفید است. نیازمندی‌ها معمولاً شامل یک میزبان Linux با پشتیبانی KVM و رعایت الزامات لایسنس Windows است.

#Windows #Docker #KVM #Virtualization #DevOps #ISO #CloudNative #CI_CD

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


👑 @software_Labdon
🤝1
🔵 عنوان مقاله
The Automation Maturity Pyramid

🟢 خلاصه مقاله:
این هرم با عنوان The Automation Maturity Pyramid روشی از David Ingraham برای ارزیابی بلوغ اتوماسیون تست در چهار مرحله است: ایجاد اعتماد به نتایج تست‌ها، بازخورد کوتاه‌مدت و سریع در جریان توسعه، افزایش سرعت توسعه با تکیه بر تست‌های پایدار، و در نهایت بازخورد بلندمدت برای حفظ کیفیت در گذر زمان. ایده اصلی این است که اتوماسیون باید هدفمند باشد: ابتدا تست‌های قابل‌اعتماد و غیرلغزان برای مسیرهای حیاتی بسازیم، سپس بازخورد سریع در CI و روی هر تغییر فراهم کنیم، بعد با کاهش زمان چرخه و افزایش اطمینان، توسعه را شتاب دهیم، و در پایان با چک‌های دوره‌ای، سنجه‌های عملکرد و نشانه‌های تولید، سلامت بلندمدت سیستم را پایش کنیم. این چارچوب به تیم‌ها کمک می‌کند شکاف‌ها را بشناسند، سرمایه‌گذاری‌ها را اولویت‌بندی کنند و از دام‌هایی مثل تمرکز زودهنگام بر پوشش یا سرعت بدون اعتماد پرهیز کنند.

#TestAutomation #AutomationMaturity #SoftwareTesting #QualityEngineering #DevOps #CICD #FeedbackLoops #SoftwareDelivery

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


👑 @software_Labdon
Forwarded from Bardia & Erfan

♨️ راز خواب 12 ساعته پاول دورف؛ جایی که ایده‌های تلگرام شکل می‌گیرن!

▪️پاول دورف، مدیرعامل تلگرام، گفته روزی بین ۱۱ تا ۱۲ ساعت می‌خوابه ، و جالبه که اینو نه تنبلی، بلکه منبع اصلی ایده‌های درخشانش می‌دونه!

▪️دورف صبح‌ها حتی سراغ گوشی هم نمی‌ره، چون معتقده موبایل‌ها جلوی تفکر مستقل رو می‌گیرن.

خودش می‌گه:

«می‌خوام خودم تصمیم بگیرم چی تو زندگیم مهمه، نه اینکه شرکت‌ها یا الگوریتم‌ها برام تعیین کنن.»

🔵 عنوان مقاله
This one feature from Cypress I didn't know I needed

🟢 خلاصه مقاله:
کنیت Bati تجربه‌ی مهاجرت یک مجموعه تست انتها‌به‌انتها از Cypress به Playwright را روایت می‌کند و نشان می‌دهد تفاوت‌های کوچک چقدر در کار روزمره اثر دارند. مهم‌ترین غافلگیری او فقدان همان قابلیت «گزارش فرمان‌ها با عکس‌های لحظه‌ای DOM و زمان‌گردانی» در Cypress بود؛ قابلیتی که عیب‌یابی ناپایداری و اشکالات انتخاب‌گرها را بسیار سریع می‌کرد.

در Playwright او با فعال‌کردن Trace Viewer، استفاده هدفمند از trace در CI، تکیه بر auto-waiting و assertionهای دقیق‌تر، و افزودن خروجی‌های کمکی (لاگ شبکه، اسکرین‌شات‌های هدفمند) بیشترِ آن بازخورد را جبران کرد. با استاندارد کردن test idها و کمی بازطراحی تست‌ها برای حذف فرض‌های زمانی، جریان کاری جدید شکل گرفت و در نهایت با سرعت اجرای بالاتر به پایداری مشابه رسیدند.

جمع‌بندی: هیچ‌کدام بر دیگری مطلقاً برتری ندارند؛ اما ارگونومی ابزار سرعت تیم را می‌سازد. در مهاجرت، زمان بگذارید تا چرخه‌های بازخورد محبوب‌تان را بازسازی کنید و جاهایی که همتای مستقیم ندارند، عادت‌های جدید بسازید. این‌گونه می‌توان مزایای Playwright را به‌دست آورد بدون از دست دادن تجربه توسعه‌دهنده‌ای که با Cypress داشتید.

#Cypress #Playwright #E2ETesting #TestAutomation #Migration #QA #JavaScript

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


👑 @software_Labdon
1
🔵 عنوان مقاله
Contain or be contained: The security imperative of controlling autonomous AI (4 minute read)

🟢 خلاصه مقاله:
امنیت سایبری وارد مرحله‌ای شده که نبردها با سرعت ماشین انجام می‌شوند؛ حملات مبتنی بر AI می‌توانند در چند میلی‌ثانیه شبکه‌ها را کاوش کنند، زنجیره‌ای از سوءاستفاده‌ها بسازند و زیرساخت‌های حیاتی را دستکاری کنند، در حالی‌که عملیات انسانی برای دیدن الگوهای هماهنگ، ساعت‌ها زمان می‌برد. نویسنده می‌گوید تمرکز بر «اخلاقی کردن» AI راه‌حل عملی نیست؛ باید AI را مهار کرد: سیستم‌های احتمالاتی را آزاد بگذاریم اما فقط در مرزهای کنترلی قطعی و غیرقابل‌انعطاف. مهار مؤثر یعنی معماری چندلایه با least privilege و قابلیت‌محور، اجرای sandbox، policy engineهای ازپیش‌تعریف‌شده، بررسی مداوم قواعد و محدودیت‌ها، پایش بلادرنگ، tripwire و circuit breaker خودکار، ثبت و ممیزی کامل، امکان rollback فوری و ایزوله‌سازی control plane بر مبنای اصول zero trust و attestation. در این الگو، انسان از حلقه واکنش لحظه‌ای بیرون می‌آید اما در حلقه راهبردی باقی می‌ماند: تعیین هدف، سیاست‌گذاری، تنظیم ریسک و بازبینی نتایج، در حالی‌که ماشین‌ها پاسخ‌های سریع را فقط در مرزهای سخت اجرا می‌کنند. پیام اصلی روشن است: یا مهار می‌کنید یا مهار می‌شوید؛ برای حفاظت از زیرساخت‌های حیاتی باید همین امروز مهار عملی و قابل‌راستی‌آزمایی را پیاده‌سازی کنیم.

#Cybersecurity #AI #AutonomousAgents #Containment #ZeroTrust #CriticalInfrastructure #SecurityArchitecture #MachineSpeed

🟣لینک مقاله:
https://cyberscoop.com/security-automonous-ai-threat-response/?utm_source=tldrinfosec


👑 @software_Labdon