فیچر های ++C توی ورژن های 2020 2017 2014 2011 رو به صورت یه جا همشو اینجا جمع کردن با توضیح کوتاه و ساده:

https://github.com/AnthonyCalandra/modern-cpp-features

<Nimo/>

جدا از مهندسی پشت تلگرام که بهینه نوشته شده، تلگرام چیزی داره به اسم Update Queue. چیزی که ۱ سال از دوران جوونیم رو صرف مهندسی معکوسش کردم.
تلگرام برای پوش کردن تغییرات مثل پیام جدید، ادیت، ری اکشن، تایپینگ و… به کلاینت‌ها از سرویس Updates تو پروتکل MTProto استفاده میکنه، ایده ی کلی و کلیدی خیلی ساده اس و اینه که کلاینت ها یه state محلی نگه میدارن و آپدیتارو دقیقا با ترتیب درست اعمال میکنن؛ اگه شکافی بینشون افتاد، Difference می‌گیرن و دوباره پرش میکنن.

چرا اینکارو کرده و کلا چالشا چیه؟
• ترتیبش مهمه چون ممکنه یه اپدیت وابسته به چیزی باشه که توی خود همون پچ میاد
• تحویل دقیق باید انجام بشه و هیچی گم نشه
• مقیاسش هم میلیون‌ها کاربر همزمان باید بگیرنش، مثل کانال های بزرگ

از اونجایی که هر پیامرسان منبع عظیمی از اتفاقاتیه که هر لحظه میوفته ما میتونیم اسم این اتفاقات رو event بزاریم. تلگرام هم یه پیامرسان مولتی کلاینته، یعنی هر کاربر میتونه چندین دیوایس برای یه حساب داشته باشه، پس وقتی یه ایونت اتفاق میوفته که باید یه کاربر از اون خبردار بشه باید اون ایونت رو به دیوایس های دیگه ی کاربر هم بفرسته، حدودا با مرتبه زمانی On^2.

مکانیزم اینجوریه که وقتی دیوایسی انلاین باشه و سوکت همون سوکتی باشه که keep alive هست یا اخرین rpc رو کال کرده سرور ایونت رو توی queue برای اون دیوایس نگه نمیداره و مستقیم میفرسته به کلاینت، حالا از اونجایی که کلاینت های دیگه ممکنه افلاین باشن یا حتی توی بکگراند پروسسشون کیل شده باشه عقب میمونن. حالا وقتی اون دیوایسی که عقب مونده بود با باز شدن سوکتش درخواست گرفتن اپدیت هارو وقتی که افلاین بوده رو از سرور میکنه و اطلاعات لوکالش رو میفرسته به سرور، من برای ساده شدنش اینجوری میگم که دیوایس میاد به سرور میگه من تا این زمان t رو داشتم و بعد این رو بهم بده، سرور هم میاد حساب کتابش رو میکنه و جواب رو توی یه پچ میفرسته! حالا چی توی این پچ هست و چی رو میفرسته رو میتونم یه رشته توییت دیگه در موردش بزنم.

حالا اگه اعدادی که توی پچ میاد با اعداد توی کلاینت نخونه عملا میگیم گپ اتفاق افتاده، برای همین هم کلاینت باید رکویست getDiff رو بزنه.
رکویست updates.getDifference به کلاینت اجازه می‌ده بگه:
من الان pts = X و seq = Y هستم و هر چی بین این و حالت جدید هست بهم بده.
• سرور ممکنه جواب بده:
difference: همه ی آپدیت های گمشده
differenceSlice: بخشی از آپدیت ها یعنی هنوز باید به فچ کردن ادامه بدی
differenceEmpty: چیزی تغییر نکرده

جالبترش اینه که توی نسخه های جدیدترش برای کانال ها مکانیسم جدا getChannelDifference هست، چون هر کانال pts مستقل داره و این باعث میشه شما فقط کانال هایی رو بگیری که تغییر کردن! برای سوپر گروه هم مکانیزم همینه.

این باعث می‌شه حتی اگر چند ساعت آفلاین باشی، بعد از اتصال دوباره دقیقاً همه‌چی رو بگیری و هیچ پیامی رو از دست ندی

حتی با packet loss یا reconnect، state کلاینت خراب نمیشه و سرور مجبور نیست برای هر کلاینت همه چی رو دوباره بفرسته. فقط gap ها sync میشن

<Abolfazl/>

🔵 عنوان مقاله
Cypress — How to Create Automatic Weekly Flake Alerting

🟢 خلاصه مقاله:
این مقاله نشان می‌دهد چگونه برای تست‌های flaky در Cypress یک سیستم هشدار هفتگی خودکار بسازیم. ابتدا با جمع‌آوری خروجی‌های قابل‌ماشین از CI (مثل JUnit/JSON) و ذخیره‌سازی نتایج هر اجرا، داده‌های لازم گردآوری می‌شود. سپس با محاسبه نرخ فلاکی در سطح تست و فایل، مقایسه هفتگی و شناسایی «پرتکرارترین» موارد، مهم‌ترین منابع ناپایداری مشخص می‌گردد. در ادامه، یک کار زمان‌بندی‌شده هفتگی گزارش خلاصه را به Slack یا ایمیل ارسال می‌کند و لینک‌هایی برای بررسی تاریخچه و اجرای‌های مشکل‌دار ارائه می‌دهد. در نهایت، با یک فرآیند تیمی ساده—تریاژ هفتگی، ایجاد تیکت، قرنطینه موقت تست‌های بد و تعیین آستانه/SLO—می‌توان نویز را کاهش داد، پایداری CI را افزایش داد و اعتماد توسعه‌دهندگان را بهبود بخشید.

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

➖➖➖➖➖➖➖➖
👑 @software_Labdon

ارتباط IPv6 از سمت زیرساخت کشور دچار اختلال و قطعی شده است.

🔵 عنوان مقاله
Testing AI: 5 obstacles and 7 workarounds

🟢 خلاصه مقاله:
این گفت‌وگو یک ساعتۀ نیکیتا سیدروویچ با مایکل بولتن به چالش‌های آزمون‌پذیری هوش مصنوعی می‌پردازد. پنج مانع اصلی شامل مسئلۀ اوراکل (نامشخص بودن پاسخ درست), غیرقطعی بودن خروجی‌ها, ابهام‌پذیری مدل, مشکلات کیفیت و偏‌داری داده, و فرسایش/دریفت در گذر زمان مطرح می‌شود. در برابر آن، هفت راهکار عملی پیشنهاد می‌شود: تعریف چند اوراکل و بازه‌های پذیرش، اتکا به سنجه‌های آماری و مقایسه با مبنا، ساخت داده‌های آزمون متنوع و سناریومحور (از جمله مصنوعی و خصمانه)، ارتقای مشاهده‌پذیری و ارزیابی پس از استقرار، آزمون اکتشافی و مبتنی بر ریسک با مشارکت ذی‌نفعان، افزودن ریل‌های ایمنی و انسان در حلقه برای تصمیم‌های حساس، و ارزیابی/نسخه‌بندی مداوم با حلقه‌های بازخورد. جمع‌بندی گفتگو بر تغییر نگرش تأکید دارد: آزمون هوش مصنوعی بیش از اثبات درستی، درباره توصیف رفتار، مدیریت ریسک و تصمیم‌سازی آگاهانه است.

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

➖➖➖➖➖➖➖➖
👑 @software_Labdon

امروز یکی از همکارانم سوال خوبی پرسید که فکر می‌کنم دغدغه خیلی‌هاست:
"فرق واقعی Async و Concurrency چیه؟ مگه هر دو به معنی انجام همزمان کارها نیستن؟"
این دو مفهوم اغلب با هم اشتباه گرفته می‌شن. بذارید با یک مثال ساده تفاوتشون رو باز کنم:
۱. Synchronous vs. Asynchronous
این مفاهیم درباره انتظار کشیدن هستن.
Sync
مثل اینه که بری کافه، قهوه سفارش بدی و همونجا جلوی پیشخوان منتظر بمونی تا آماده بشه و تحویل بگیری.
تا قهوه رو نگیری، هیچ کار دیگه‌ای نمی‌کنی.
Async
سفارش می‌دی، یک پیجر (Pager) می‌گیری و می‌ری سر میزت می‌نشینی.
در این فاصله می‌تونی ایمیل‌هاتو چک کنی.
هر وقت قهوه‌ات آماده شد، پیجر بهت خبر می‌ده.
تو منتظر نموندی و از زمانت استفاده کردی.

۲. Concurrency
این مفهوم درباره مدیریت چند کار در یک بازه زمانی هست.
باریستای کافه رو در نظر بگیرید:
اون همزمان هم سفارش شما رو آماده می‌کنه، هم سفارش نفر بعدی رو می‌گیره و هم شیر رو برای یک سفارش دیگه گرم می‌کنه.
در واقع اون با جابجایی سریع بین کارها (Context Switching)، چند وظیفه رو پیش می‌بره.
این یعنی هم‌روندی.

نکته کلیدی
برنامه‌نویسی Async یکی از راه‌های رسیدن به Concurrency هست.
درک این تفاوت، در طراحی سیستم‌های مدرن مثل میکروسرویس‌ها یا پایپ‌لاین‌های پردازش دیتا، یک مزیت فوق‌العاده است.
این درک به شما کمک می‌کنه تا بین ابزارهایی مثل Kafka, gRPC یا WebSockets انتخاب درستی داشته باشید و سیستمی بسازید که هم Scalable و هم Reliable باشه.


@ | <Ali Naseri/>

🔵 عنوان مقاله
My Journey: How I Mastered Test Automation

🟢 خلاصه مقاله:
ناوین خونته‌تا مسیر یادگیری خود در خودکارسازی تست را روایت می‌کند و نشان می‌دهد که تمرکز بر اصول پایه، رویکرد مهندسی به کدنویسی و تمرین مستمر کلید موفقیت است. او توصیه می‌کند یک پشته فناوری را عمیق یاد بگیرید، پروژه‌های کوچک بسازید، کد تمیز و قابل نگهداری بنویسید و از الگوهایی مانند انتزاع لایه‌ای برای کاهش شکنندگی تست‌ها بهره ببرید. مدیریت فِلِیکی بودن، داده و محیط تست، یکپارچه‌سازی با CI/CD، گزارش‌دهی و لاگ‌های قابل اقدام، و همسویی با هرم تست و اهداف محصول از محورهای اصلی اوست. در نهایت، با نقشه راه، جامعه‌پذیری و ثبت دستاوردها، می‌توان یادگیری را پایدار کرد و خودکارسازی تست را به مهارتی بلندمدت و اثرگذار تبدیل کرد.

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

➖➖➖➖➖➖➖➖
👑 @software_Labdon

🔵 عنوان مقاله
Why You Should Write More Context Tests and Fewer Unit Tests

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

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

➖➖➖➖➖➖➖➖
👑 @software_Labdon

بروزرسانی امنیتی جدید مایکروسافت کابوس کاربران شد...!

▪️آپدیت امنیتی آگوست 2025 برای ویندوز 10 و 11 باعث مشکلات جدی شده؛ تا جایی که بعضی کاربرا حتی نمی‌تونن برنامه‌ها رو نصب کنن.

▪️این آپدیت بخش UAC (کنترل حساب کاربری) رو خیلی سخت‌گیر کرده و کاربرای غیرادمین برای نصب یا اجرای بعضی برنامه‌ها مجبور به وارد کردن پسورد ادمین می‌شن.

+ در بعضی موارد هم برنامه‌ها اصلاً اجرا نمی‌شن ؛ مایکروسافت این مشکل رو تأیید کرده و احتمالاً به‌زودی یک پچ اصلاحی منتشر می‌کنه.

🔵 عنوان مقاله
From Chaos to Clarity: My Journey with QA Test Documentation

🟢 خلاصه مقاله:
** این مقاله با روایت تجربه مدهومینی کُدیتوواکّو نشان می‌دهد برای مقدار مستندسازی تست، قاعده ثابتی وجود ندارد؛ میزان و جزئیات اسناد باید متناسب با زمینه تعیین شود. معیارهای اصلی تصمیم‌گیری عبارت‌اند از هدف سند (ارتباط، هم‌راستاسازی، مدیریت ریسک)، سطح ریسک و پیچیدگی سیستم، الزامات انطباقی، و نیازهای تیم. رویکرد پیشنهادی «به‌اندازه کافی» است: در محیط‌های چابک از دارایی‌های سبک مثل چک‌لیست و چارتر استفاده کنید و در حوزه‌های پرریسک یا مقرراتی به سراغ اسناد رسمی‌تر و ردیابی‌پذیر بروید. اسناد باید زنده، نسخه‌دار، مرتبط با داستان‌ها و باگ‌ها، و به‌طور منظم بازبینی شوند. پرهیز از دام کاغذبازی، تکرار غیرضروری و اسناد بی‌مصرف ضروری است. نتیجه این رویکرد، شفافیت، تحویل قابل پیش‌بینی‌تر، ردیابی بهتر نقص‌ها و تمرکز تست بر ریسک‌های مهم است.

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

➖➖➖➖➖➖➖➖
👑 @software_Labdon

🔵 عنوان مقاله
Test Automation Guardrails

🟢 خلاصه مقاله:
افزایش تولید کد توسط هوش مصنوعی ریسک خطا، حفره‌های امنیتی و رفتارهای پیش‌بینی‌نشده را بیشتر می‌کند. اتکا به بررسی دستی کافی نیست؛ تست خودکار باید به‌عنوان نرده‌بان‌های ایمنی عمل کند و رفتار مورد انتظار را به‌صورت مشخصات اجرایی تثبیت کند. یک رویکرد لایه‌ای شامل تست‌های واحد، یکپارچه/قراردادی و سرتاسری، همراه با تحلیل ایستا و اسکن امنیتی، پوشش گسترده‌تری می‌دهد و در CI/CD تغییرات پرخطر را مسدود می‌کند. کیفیت و پایداری تست‌ها (کاهش فلیکینس، معنابخشی، سنجش اثربخشی) حیاتی است و هرچند هوش مصنوعی می‌تواند در تولید تست کمک کند، تأیید انسانی ضروری است. در نهایت، با پرچم‌های ویژگی، استیجینگ/کناری و مشاهده‌پذیری، محافظت تا تولید ادامه می‌یابد؛ نتیجه اینکه در عصر کد تولیدشده توسط AI، اتوماسیون تست مهم‌ترین سپر ایمنی است.)

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

➖➖➖➖➖➖➖➖
👑 @software_Labdon

کد ۴۸ ساله معروف بیل گیتس، اوپن‌سورس شد!
مایکروسافت کد ۴۸ ساله‌ی معروف بیل گیتس را متن‌باز کرد تا هر کسی بتواند آن را ببیند و استفاده کند.

https://github.com/microsoft/BASIC-M6502

| <Saber V/>

زبان C یاد بگیرید.

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

درهای جدیدی در ذهن‌تون باز میشه.

<Amirreza Gh/>

🔵 عنوان مقاله
Automation Maturity Matrix & Test Pyramid

🟢 خلاصه مقاله:
این مقاله یک شیوه ارزیابی عملی برای کیفیت و اتوماسیون تست ارائه می‌کند که هرم تست را با سنجش بلوغ فرایند ترکیب می‌کند. با تکیه بر اصول هرم تست، توزیع متعادل میان تست‌های واحد، یکپارچه و انتها‌به‌انتها بررسی می‌شود و در عین حال ابعاد فرایندی مانند راهبرد، ابزارها، CI/CD، مدیریت داده و ناپایداری، پوشش و گزارش‌دهی امتیازدهی می‌گردد. خروجی مدل یک امتیاز بلوغ است که به تیم‌ها کمک می‌کند وضعیت خود را بسنجند، ضد‌الگوهایی مانند «هرم وارونه» و تست‌های شکننده را شناسایی کنند و برای بهبود مستمر برنامه‌ریزی کنند.

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

➖➖➖➖➖➖➖➖
👑 @software_Labdon

🔵 عنوان مقاله
Get better test reports from Playwright

🟢 خلاصه مقاله:
Playwright گزارش‌دهنده‌های داخلی قدرتمندی دارد، اما در پروژه‌های بزرگ‌تر معمولاً به شفافیت بیشتر در سطح «گام‌های تست» نیاز است. این مقاله با اشاره به یک نکته عملی از کریس انیتان نشان می‌دهد چطور می‌توان خروجی تست‌ها را طوری شفاف‌تر کرد که هر مرحله با هدف و معنای روشن در گزارش بیاید. نتیجه، رفع خطا سریع‌تر، بازخورد دقیق‌تر در CI و کاهش زمان تحلیل علت خرابی تست‌هاست.

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

➖➖➖➖➖➖➖➖
👑 @software_Labdon

📂 یه فایل فوق‌العاده آماده کردیم براتون!

🔹 لیست ۶۴ شرکت بزرگ دنیا که از Golang استفاده می‌کنن
🔹 همراه با موقعیت‌های شغلی فعال Golang توی همین شرکت‌ها

اگه دنبال فرصت‌های شغلی توی حوزه Backend، DevOps یا Software Engineering هستی، این فایل می‌تونه یه نقطه شروع عالی باشه.

📌 همین الان فایل رو بردار و شرکت‌ها + موقعیت‌ها رو ببین

@gopher_job

🔵 عنوان مقاله
Why Tests Aren't Enough (And What Actually Keeps Code Safe)

🟢 خلاصه مقاله:
تست‌ها لازم‌اند اما برای ایمن‌سازی نرم‌افزار کافی نیستند؛ چون فقط رفتارهای پیش‌بینی‌شده را می‌سنجند و می‌توانند حس امنیت کاذب ایجاد کنند. راه‌حل، رویکرد مبتنی بر ریسک است: شناسایی دارایی‌ها و مسیرهای حیاتی، تحلیل تهدیدها، و اولویت‌بندی بر اساس اثر و احتمال. امنیت واقعی با دفاع لایه‌ای به دست می‌آید: معماری و مرزبندی درست، بازبینی کد، آنالیز ایستا/پویا، مدیریت وابستگی‌ها، و در بُعد عملیاتی مشاهده‌پذیری، کَنری و فلگ ویژگی، رول‌بک سریع، محدودسازی نرخ و تایم‌اوت. فرهنگ مهندسی نیز مهم است: مستندات طراحی همراه با مدل‌سازی تهدید، چک‌لیست‌ها، پسا‌تحلیل بی‌سرزنش، و مالکیت و ران‌بوک‌های روشن. پیام نهایی: به‌جای تمرکز بر درصد پوشش تست، به مهندسی آگاه از ریسک روی بیاورید و تست را در کنار کنترل‌های چندلایه و آمادگی عملیاتی به‌کار بگیرید.

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

➖➖➖➖➖➖➖➖
👑 @software_Labdon

🚀 رفع هشدارهای Git GC (Garbage Collection)

گاهی وقتا موقع اجرای git pull یا git fetch با پیام‌های زیر مواجه میشید:

warning: The last gc run reported the following. Please correct the root cause and remove .git/gc.log
warning: There are too many unreachable loose objects; run 'git prune' to remove them.

این هشدارها یعنی ریپازیتوری شما پر از فایل‌های قدیمی و objectهای غیرقابل دسترس شده. برای پاکسازی و بهینه‌سازی کافیه مراحل زیر رو انجام بدید:

---

🔹 مرحله ۱: پاک کردن لاگ قدیمی GC

rm -f .git/gc.log

🔹 مرحله ۲: حذف objectهای غیرقابل دسترس

git prune

🔹 مرحله ۳: اجرای Garbage Collection به‌صورت کامل و تهاجمی

git gc --aggressive --prune=now

---

✅ اگه بخواید همه‌ی مراحل رو یکجا اجرا کنید:

rm -f .git/gc.log && git prune && git gc --aggressive --prune=now

بعد از این کار، ریپازیتوری سبک‌تر میشه و دیگه این هشدارها رو نمی‌بینید ✨

➖➖➖➖➖➖➖➖
👑 @software_Labdon

🔵 عنوان مقاله
The Blame Game in Software: Why QA Isn't Your Firefighter

🟢 خلاصه مقاله:
این مقاله می‌گوید نگاه سنتی به QA به‌عنوان «آتش‌نشانِ انتهای چرخه» هم کهنه است و هم مضر. انداختن بار کیفیت بر دوش تستِ مرحله‌ی پایانی باعث بازخورد دیرهنگام، هزینه‌ی اصلاح بالا، تعارض نقش‌ها و فرسودگی می‌شود. رویکرد درست، کیفیتِ «درون‌ساخته» و مسئولیت مشترک کل تیم است: شیفت-چپ با دخالت زودهنگام QA در نیازمندی و طراحی، تعریف معیارهای پذیرش، مالکیت تست‌های واحد و یکپارچه توسط توسعه‌دهندگان، خودکارسازی معنادار و CI/CD برای بازخورد سریع، و تمرکز QA بر مدیریت ریسک و آزمون اکتشافی. فرهنگِ بدون سرزنش، پسامرتکب‌های یادگیرنده و سنجه‌های پیشرو، بهبود مداوم را ممکن می‌کند. به‌گفته‌ی گنگا پاندی، QA باید مربی و شریک کیفیت باشد نه آتش‌نشان؛ نتیجه، تحویل سریع‌تر، پایدارتر و با اعتماد بیشتر است.

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

➖➖➖➖➖➖➖➖
👑 @software_Labdon

🔵 عنوان مقاله
Set up a Playwright Browser Server in AWS EC2

🟢 خلاصه مقاله:
** این مقاله پیشنهاد می‌کند برای اجرای تست‌های Playwright روی چند مرورگر (Chromium، Firefox و WebKit) به‌جای نصب مرورگرها روی هر ماشین، یک Browser Server متمرکز روی AWS EC2 راه‌اندازی کنید؛ ایده‌ای که توسط تانانجایان راجاسکاران مطرح شده است. با راه‌اندازی مرورگرها در حالت سرور و اتصال از راه دور از طریق WebSocket، نصب و به‌روزرسانی محلی حذف می‌شود و پایداری، مقیاس‌پذیری و استفاده از منابع بهبود می‌یابد. مقاله به مراحل کلی استقرار (انتخاب EC2، نصب Playwright یا استفاده از ایمیج‌های Docker، مدیریت فرآیند)، الزامات امنیتی شبکه (VPC خصوصی، TLS/SSH، احراز هویت) و نکات عملیاتی (مانیتورینگ، ایزوله‌سازی نشست‌ها، مقیاس‌پذیری و مدیریت هزینه) می‌پردازد. نتیجه این رویکرد، اجرای یکپارچه و قابل‌اعتماد تست‌ها روی چند مرورگر با نگهداشت ساده‌تر است.

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

➖➖➖➖➖➖➖➖
👑 @software_Labdon