داخل "کار باشه" (گروهمون )

به طور فعال داریم همه موقعیت های شغلی که توی لینکدین و تلگرام و توییتر و باقی سوشال مدیا هست رو باهم به اشتراک میزاریم تا زودتر بتونیم افرادی که تعدیل شدن رو به بازار کار معرفی کنیم

خوبیه کار باشه اینه که دسته بندی داره یعنی شما بر اساس توانایی شغلی که دارید مثلا پروداکت دیزاینر وارد تاپیک میشید و تمامی مشاغل شغلی ها رو از بالا به پایین میخونید و اپلای میکنید

اگر مایل بودید حتما جوین بشید به گروهمون

@job_bashe

بریم ادامه قوانین مهندسی نرم افزار

لینوس لاو ( یا قانون لینوس ) یه ایده معروف تو دنیای برنامه‌نویسیه که میگه: «اگه آدم‌های زیادی کد رو ببینن، پیدا کردن باگ‌ها راحت‌تر میشه.» یعنی وقتی یه پروژه اوپن‌سورس باشه و کلی دولوپر و کاربر بهش دسترسی داشته باشن، احتمال اینکه یکی مشکل رو پیدا کنه یا حتی براش راه‌حل بده خیلی بیشتره. چیزی که برای یه برنامه‌نویس پیچیده و گیج‌کننده‌ست، شاید برای یه نفر دیگه خیلی واضح باشه. به خاطر همین پروژه‌هایی مثل لینوکس یا Apache معمولاً سریع‌تر باگ‌هاشون کشف و درست میشه.

البته این قانون همیشه هم معجزه نمی‌کنه. فقط اوپن‌سورس بودن کافی نیست؛ باید آدم‌هایی واقعاً در حال بررسی و مشارکت باشن. مثلاً باگ معروف Heartbleed توی OpenSSL دو سال مخفی مونده بود، با اینکه پروژه کاملاً متن‌باز بود. یعنی «چشم زیاد» وقتی مفیده که واقعاً کسی داره نگاه می‌کنه. به همین خاطر این قانون بیشتر از اینکه یه حقیقت مطلق باشه، یه یادآوریه که همکاری، شفافیت و کد ریویو جمعی معمولاً کیفیت نرم‌افزار رو بهتر می‌کنه.

#lawsofsoftwareengineering

@codehalics | کدهالیک

FYI : For Your Information

باگ معروف Heartbleed یه حفره امنیتی خیلی خطرناک توی کتابخونه‌ی OpenSSL بود که سال ۲۰۱۴ کشف شد. OpenSSL همون چیزیه که خیلی از سایت‌ها برای رمزنگاری و HTTPS ازش استفاده می‌کنن. مشکل از یه قابلیت به اسم “Heartbeat” اومده بود؛ هکر می‌تونست به سرور یه درخواست تقلبی بفرسته و سرور بدون بررسی درست، بخشی از حافظه‌ی خودش رو پس بده. تو اون حافظه ممکن بود اطلاعات خیلی حساس مثل پسورد، کوکی لاگین، پیام‌ها یا حتی کلید خصوصی SSL وجود داشته باشه.

چیزی که Heartbleed رو ترسناک‌تر کرد این بود که این باگ حدود دو سال توی یه پروژه‌ی اوپن‌سورس بسیار معروف وجود داشت و کسی متوجهش نشده بود. این دقیقاً شد ضد مثال معروف برای Linus’s Law؛ یعنی صرف اینکه کد جلوی چشم همه باشه کافی نیست، باید آدم‌های متخصص واقعاً کد رو بررسی کنن. بعد از افشای باگ، کلی سایت بزرگ مجبور شدن سریع OpenSSL رو آپدیت کنن، سرتیفیکیت‌هاشون رو عوض کنن و از کاربرها بخوان پسوردهاشون رو تغییر بدن.

@codehalics | کدهالیک

من یه پوریا لاو هم دارم ( لاو لایفم رو نمیگم منظورم قانون من در آوردی خودمه) که میگم اگر یه کد رو به چندتا ایجنت هوش مصنوعی بدی معمولا نتیجه بهتری میگیری بنظرم آپدیت این قانون الان اینشکلیه که فقط از جمنای و فقط از کدکس و فقط از کلاد استفاده نکنی تجمیعشون کنی و از تجمیعشون تصمیم بگیری خیلی خیلی برای من این نکته تاثیر گذاشته و دوما تست نویسی ! به هوش مصنوعی میگم تست بنویس برای این سناریو ها حالا هر وقت کدو تغییر بده تست ها پاس نشه میگم دیدی نشد دیدی پی پی کردی تو کد من!! بعد اینطوری میتونم جلوی خیلی از unexpected behaviors هارو بگیرم
یه بار پوریا لاو رو تست کنین شگفت زدتون میکنه !

@codehalics | کدهالیک

یه مفهوم من درآوردی دیگ هم داریم به اسم Rubber Duck Debugging

معمولا من توی دخترای برنامه نویس دیدم میرن عروسکش میخرن براش باگارو توضیح میدن اگر پسرشو دیدید لطفا گزارش بدید که بریم پیگیری کنیم چی شده اینکارو داره میکنه

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

فرقش با Linus’s Law اینه که اون میگه «چشم‌های بیشتر = احتمال بیشتر برای پیدا شدن باگ»، ولی Rubber Duck Debugging میگه «شفاف توضیح دادن مسئله = احتمال بیشتر برای فهمیدن باگ».
هردوشون روی این ایده سوارن که باگ وقتی از حالت مبهم توی ذهنت خارج بشه، پیدا کردنش راحت‌تر میشه.

البته بازم بگم همه اینارو اون طرفش هوش مصنوعی بزارید دیگ یعنی هوش مصنوعی بشه نقش اون رابر داک و نقش چشم هایی که باید باگ هارو پیدا کنند چون واقعا داریم از اون نسل که باید ساعت ها میشستی دیباگ میکردی تا مشکل پیدا کنی گذر میکنیم چون الان ایزی ایزی کلاد همه اینکارارو به بهترین شکل برات میکنه !

@codehalics | کدهالیک

فک کنم فقط منم که از مرگ آدمای بی گناه ناراحت میشم :) نه؟

@codehalics | کدهالیک

کلودفلر امروز یه مقاله ای رو منتشر کرد راجب به اینکه چطوری بعد از اون باگ خطرناک CopyFail
یعنی همونی که لینوکس های ۲۰۱۷ به بعد رو دسترسی روت میشد روشون گرفت رو روی همه سروراش پچ کرده اونا تو مقاله ای که امروز ریلیز کردن گفتن :

وقتی آسیب‌پذیری Copy Fail منتشر شد، تیم‌های امنیت و مهندسی Cloudflare تقریباً همزمان وارد عمل شدن. اول از همه بررسی کردن که کدوم نسخه‌های کرنل داخل زیرساختشون آسیب‌پذیره و چقدر از سرورها درگیرن. همزمان تیم امنیت exploit رو تحلیل کرد تا بفهمه حمله دقیقاً چه رفتاری روی سیستم ایجاد می‌کنه. نکته جالب این بود که سیستم تشخیص رفتار مشکوک Cloudflare بدون هیچ آپدیت یا rule جدیدی، همون موقع exploit رو شناسایی کرد و alert داد. یعنی ابزارشون فقط دنبال «اسم باگ» نبود؛ رفتار غیرعادی مثل تلاش برای privilege escalation رو تشخیص می‌داد. بعد از اون، تیم امنیت شروع کرد کل لاگ‌ها و فعالیت سرورها رو برای ۴۸ ساعت گذشته بررسی کردن تا مطمئن بشن قبل از عمومی شدن باگ کسی ازش سوءاستفاده نکرده. حتی hash فایل‌های سیستمی و ارتباطات شبکه رو هم چک کردن تا اثری از دستکاری یا persistence وجود نداشته باشه.

از اون طرف تیم کرنل باید سریع جلوی exploit رو می‌گرفت، ولی مشکل این بود که patch کامل نیاز به آپدیت و reboot تعداد خیلی زیادی سرور داشت و این کار زمان‌بره. برای همین اول یک mitigation موقت ساختن. اونا با استفاده از eBPF و bpf-lsm اومدن دسترسی به بخش آسیب‌پذیر کرنل رو فقط برای برنامه‌هایی که واقعاً لازم داشتن باز گذاشتن و بقیه درخواست‌ها رو بلاک کردن. قبل از فعال کردن این محدودیت هم کل زیرساخت رو مانیتور کردن تا مطمئن شن سرویس مهمی ناخواسته قطع نمیشه. بعد از آماده شدن patch رسمی لینوکس، کرنل جدید رو اول داخل دیتاسنترهای staging تست کردن و بعد کم‌کم با سیستم rollout خودشون روی کل شبکه deploy کردن. نتیجه نهایی این بود که بدون downtime جدی و بدون آسیب به مشتری‌ها، کل زیرساخت یا patch شد یا زیر mitigation امن قرار گرفت.

https://blog.cloudflare.com/copy-fail-linux-vulnerability-mitigation/

@codehalics | کدهالیک

Only legends know

@codehalics | کدهالیک

خب دوستان خوشبو بودیم جلوی کولرم نشستیم ! مثل که دوباره جنگ شروع شد 🙂

#off_topic

@codehalics | کدهالیک

OmniRoute

یه هاب هوش مصنوعیه برای برنامه‌نویسا؛ یعنی به‌جای درگیر شدن با تحریم، quota، قطع شدن Claude یا محدودیت GPT، همه مدل‌های AI رو از یه آدرس واحد مدیریت می‌کنی. خودش بین Claude، GPT، Gemini، DeepSeek و حتی مدل‌های رایگان سوییچ می‌کنه تا وسط کار coding گیر نکنی. برای ابزارهایی مثل Cursor، Cline، Claude Code و Codex ساخته شده و مخصوص کساییه که هر روز با AI کد می‌زنن.

ویژگی خفن پروژه اینه که مصرف توکن و هزینه رو شدید کم می‌کنه؛ لاگ‌ها، خروجی ترمینال و context طولانی رو فشرده می‌کنه تا هم ارزون‌تر دربیاد هم context دیرتر پر بشه. تازه سیستم proxy و bypass تحریم هم داره، برای همین بین دولوپرهای ایران، روسیه و کشورهایی که سرویس‌های AI محدودن خیلی محبوب شده؛ عملاً یه «مرکز کنترل AI» می‌سازه که همیشه یه مدل آماده‌ی fallback داره تا کارت نخوابه.

https://github.com/diegosouzapw/OmniRoute

@codehalics | کدهالیک

این مقاله داره میگه اینترنت کم‌کم زیر حجم محتوای کم‌ارزشِ ساخته‌شده با AI خفه میشه. مشکل از جایی شروع میشه که هر کسی با چند تا پرامپت یه اپ، مقاله، ویدیو یا repo درمیاره و سریع توی Reddit و Hacker News و Slack پخشش می‌کنه، انگار شاهکار ساخته. حرفش اینه که صرف این‌که AI تونسته چیزی برات تولید کنه، دلیل نمیشه بقیه هم باید وقتشونو صرف دیدنش کنن. به نظرش خیلی از این پروژه‌ها بیشتر هیجان لحظه‌ای‌ان تا چیزی که واقعاً به درد کامیونیتی بخوره.

اصل حرفش درباره نسبت «سیگنال به نویز» توی اینترنت امروزه. یعنی وقتی همه شروع کنن به پست کردن خروجی خام AI، پیدا کردن کار باکیفیت سخت میشه و کم‌کم آدمای واقعی و متخصص از کامیونیتی خسته میشن و کنار می‌کشن. خودش بین «استفاده خوب از AI» و «AI slop» فرق میذاره؛ اگه AI کمک کنه یه آدم واقعاً چیز مفید و فکرشده‌ای بسازه، عالیه. ولی اگر فقط برای جلب توجه، گرفتن engagement یا تولید محتوای بی‌فکر باشه، داره فضای اینترنتو نابود می‌کنه. خلاصه حرفش اینه که «با AI بساز، نه این‌که فقط خروجی AI رو روی سر بقیه خالی کنی.»

لینک مقاله

@codehalics | کدهالیک

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

به نظرم بهترین مثالش تفاوت فرش دستباف با فرش ماشینیه. فرش ماشینی تمیزتر، ارزون‌تر و سریع‌تر تولید میشه، ولی اون روح و حس فرش دستباف رو نداره. توی فرش دستباف، هر گره یه دلیل داره. می‌تونی از بافنده بپرسی چرا این طرح اینجاست، چرا اون رنگ عوض شده، چرا اون گره اون‌طوری خورده. پشت هر قسمتِ کار، ساعت‌ها فکر، تجربه و زندگی خوابیده. ولی فرش ماشینی فقط خروجیه؛ تمیز و دقیق، اما بی‌روح. حس می‌کنم خیلی از چیزایی که امروز با AI تولید میشن هم همینن. شاید از بیرون قشنگ و کامل به نظر برسن، ولی اون عمق، رنج، تجربه و روحی که توی کار یه آدم واقعی هست رو ندارن. شاید همه با این نگاه موافق نباشن، ولی اگر یه بار از این زاویه به موضوع نگاه کنی، احتمالاً می‌فهمی منظورم چیه.


@codehalics | کدهالیک

باز دوباره یه آسیب‌پذیری خیلی خطرناک برای لینوکس پیدا شده به اسم «Dirty Frag» که می‌تونه روی اکثر distroهای اصلی به کاربر عادی دسترسی root بده. مشکل اینجاست که exploitش عمومی شده ولی هنوز همهٔ سیستم‌ها patch نگرفتن، برای همین الان یکی از حساس‌ترین زمان‌ها برای حمله‌های لینوکسیه.

https://www.openwall.com/lists/oss-security/2026/05/07/8


@codehalics | کدهالیک

فک کنم الان فهمیدم چرا لینوس تروالدز راجب AI گفت
هوش مصنوعی الان ۹۰٪ مارکتینگ و ۱۰٪ واقعیته

بنظرم واقعیتشو توی این چند هفته که ۳ تا کریتیکال باگ روی کرنل زد متوجه بشه :))))

@codehalics | کدهالیک

این مقاله تازه نوشته شده راجب به استفاده از webRTC در ChatGPT نوشته که بنظرش کار اشتباهی بوده !

میگه استفاده از WebRTC برای Voice AI انتخاب خوبی نیست، چون WebRTC ذاتا برای تماس زنده ساخته شده، نه برای اینکه صدای کاربر با دقت کامل به مدل هوش مصنوعی برسه. توی تماس تصویری اگه اینترنت بد بشه، WebRTC برای پایین نگه داشتن تأخیر، بسته‌های صدا رو می‌ندازه دور. این برای مکالمه آدم‌ها قابل تحمله، ولی برای AI بده، چون اگه بخشی از پرامپت صوتی خراب یا حذف بشه، مدل ممکنه کل منظور کاربر رو اشتباه بفهمه. از نظر نویسنده بهتره کاربر ۲۰۰ میلی‌ثانیه بیشتر صبر کنه، ولی صدای دقیق‌تری ارسال بشه.

بخش فنی‌تر حرفش هم اینه که WebRTC در مقیاس بزرگ دردسر زیاد دارد: کلی پروتکل و استاندارد توی هم قاطی شده، راه‌اندازی اتصالش چندین رفت و برگشت شبکه می‌خواهد، load balancing سخت می‌شود و شرکت‌ها مجبور می‌شوند کلی هک و راه‌حل اختصاصی بسازند. پیشنهادش اینه که برای Voice AI اول حتی WebSocket ساده بهتره، چون با زیرساخت‌های فعلی راحت‌تر scale می‌شود. ولی در حالت ایده‌آل باید رفت سمت QUIC یا WebTransport، چون اتصال سریع‌تر، جابه‌جایی بهتر بین وای‌فای و موبایل، و load balancing تمیزتری دارد. خلاصه حرفش اینه: OpenAI کار سختی رو در مقیاس خیلی بزرگ انجام داده، ولی به نظرش اصل انتخاب WebRTC برای این محصول اشتباهه.

https://moq.dev/blog/webrtc-is-the-problem/

@codehalics | کدهالیک

⁨FYI⁩: ⁨For Your Information⁩

کوییک ( نه ماشین سایپا ) یه پروتکل جدیده که پشت ⁨HTTP/3⁩ استفاده میشه. ایده‌اش اینه که به جای ⁨TCP⁩، روی ⁨UDP⁩ کار کنه تا اتصال سریع‌تر بالا بیاد، وقتی اینترنت بالا پایین میشه بهتر دوام بیاره، و مثلا وقتی گوشی از وای‌فای میره روی دیتا، اتصال کمتر بپره.

فرقش با ⁨TCP⁩ کلاسیک اینه که فقط به ⁨IP⁩ و پورت وابسته نیست و چیزی به اسم ⁨Connection ID⁩ داره. برای همین جابه‌جایی شبکه و ⁨load balancing⁩ باهاش تمیزتر انجام میشه.

واسه همین نویسنده میگه برای ⁨Voice AI⁩، استفاده از ⁨QUIC⁩ خیلی منطقی‌تر از ⁨WebRTC⁩ عه. چون هم ⁨latency⁩ کمتری میده، هم کنترل بهتری روی ارسال داده داری، هم لازم نیست اون همه هک عجیب برای ⁨WebRTC⁩ بزنی. ⁨HTTP/3⁩ هم رسما روی ⁨QUIC⁩ تعریف شده.

حالا نکته ایران اینه که ⁨QUIC⁩ معمولا روی ⁨UDP⁩ و پورت ۴۴۳ میاد بالا. فیلترچی‌ها هم اگه نتونن دقیق و تمیز تشخیص بدن چی به چیه، راحت‌ترین کار براشون اینه که ⁨UDP/443⁩ یا خود ⁨QUIC⁩ رو کلا ببندن.

قبلا ⁨OONI⁩ درباره ایران گفته بود شواهد قوی هست که ⁨QUIC⁩، که ⁨HTTP/3⁩ بهش وابسته است، احتمالا با بستن ⁨UDP/443⁩ کامل بلاک شده بود. گزارش‌های فنی‌تر و کامیونیتی هم بعدا نوشتن که ⁨QUIC⁩ روی خیلی از شبکه‌های ایران غیرفعال یا محدود شده.

نتیجه‌اش اینه که خیلی از مرورگرها بی‌سروصدا برمی‌گردن روی ⁨HTTP/2⁩ و ⁨TCP⁩. ولی چیزهایی که واقعا روی ⁨QUIC⁩ حساب کرده باشن، مثل بعضی روش‌های تونل، ⁨VPN⁩، ⁨WebTransport⁩ یا سرویس‌های ⁨realtime⁩، یا کند میشن یا کلا نمیان بالا.

@codehalics | کدهالیک

⁨FYI⁩: ⁨For Your Information⁩

اگه بخوایم خیلی خودمونی بگیم، ⁨HTTP⁩ هم مثل خیلی چیزهای وب نسل به نسل بهتر شده.

اولش ⁨HTTP/0.9⁩ بود. خیلی ساده و خام. فقط می‌گفت یه صفحه رو بده، سرور هم همون صفحه رو برمی‌گردوند. نه ⁨header⁩ درست‌وحسابی داشت، نه ⁨status code⁩، نه چیز خاصی.

بعد ⁨HTTP/1.0⁩ اومد و وب یکم جدی‌تر شد. چیزهایی مثل ⁨header⁩، کدهای وضعیت مثل ⁨404⁩ و ⁨200⁩، و پشتیبانی بهتر از انواع فایل‌ها اضافه شد. یعنی دیگه فقط صفحه ساده ⁨HTML⁩ نبود.

بعد رسیدیم به ⁨HTTP/1.1⁩ که سال‌ها ستون فقرات وب بود. مهم‌ترین بهبودش این بود که لازم نبود برای هر درخواست یه اتصال جدید ساخته بشه. اتصال می‌تونست باز بمونه و چندتا درخواست از همون مسیر رد بشه. ولی هنوز مشکل داشت، چون درخواست‌ها تا حدی پشت هم گیر می‌کردن و برای سایت‌های سنگین امروزی ایده‌آل نبود.

بعد ⁨HTTP/2⁩ اومد و گفت به جای اینکه درخواست‌ها یکی‌یکی تو صف بمونن، چندتا درخواست همزمان از یه اتصال رد بشن. به این میگن ⁨multiplexing⁩. همچنین ⁨header⁩ها هم فشرده‌تر شدن و کلی چیز برای سرعت بهتر اضافه شد. برای همین سایت‌ها با کلی فایل ⁨CSS⁩، ⁨JS⁩، عکس و فونت بهتر لود می‌شدن.

بعدش ⁨HTTP/3⁩ اومد که تغییر اصلیش زیرساخت انتقاله. ⁨HTTP/1.1⁩ و ⁨HTTP/2⁩ معمولا روی ⁨TCP⁩ بودن، ولی ⁨HTTP/3⁩ روی ⁨QUIC⁩ کار می‌کنه، و ⁨QUIC⁩ هم روی ⁨UDP⁩ ساخته شده. نتیجه‌اش اینه که اتصال سریع‌تر بالا میاد، روی اینترنت ناپایدار بهتر جواب میده، و وقتی مثلا گوشی از وای‌فای میره روی دیتای موبایل، اتصال کمتر می‌پره.

فعلا نسل اصلی جدید همینه، یعنی ⁨HTTP/3⁩. چیزی به اسم ⁨HTTP/4⁩ به عنوان استاندارد رایج و رسمی نداریم.

@codehalics | کدهالیک

این مقاله ای که امروز خوندم و خلاصشو میخوام بهتون بگم راجب یه مدل تفکر الگوریتمی خیلی باحال صحبت میکنه
که بهش میگیم Collisions یا برخورد ها مثلا فرض کنین قراره یه آیدی برای هر کس جنریت کنیم احتمال برخورد ( تکراری شدنش ) چطوری محاسبه میشه !
از همین تفکر الگوریتمی توی اتک به یه سرور یا ریسورس استفاده میشه !

بعد میاد همین رو توی یه مثال خیلی باحال تو مقاله میگه که خلاصش اینه :

می‌گه ما معمولاً احتمال برخوردها رو کمتر از چیزی که واقعاً هست حس می‌کنیم. مثلاً فکر می‌کنیم برای اینکه دو نفر تولد یکسان داشته باشن باید جمع خیلی بزرگی باشه، ولی فقط با ۲۳ نفر احتمال این اتفاق حدود ۵۰٪ می‌شه. دلیلش اینه که ما فقط به یک جفت خاص فکر نمی‌کنیم؛ بین ۲۳ نفر کلی جفت مختلف وجود داره که هرکدوم می‌تونن تولد مشترک داشته باشن، پس شانس کلی خیلی زود بالا می‌ره.

بعد متن همین ایده رو به هش‌ها وصل می‌کنه. توی هش‌کردن، مثل اینه که آدم‌ها رو بندازیم داخل روزهای تقویم؛ فقط اینجا آدم‌ها می‌شن ورودی و روزها می‌شن خروجی ممکن هش. اگر تعداد ورودی‌ها زیاد بشه، بالاخره دو ورودی مختلف ممکنه یک خروجی هش یکسان بدن؛ به این می‌گن collision یا برخورد. Birthday Attack هم از همین استفاده می‌کنه: مهاجم دنبال یک خروجی خاص نیست، فقط می‌خواد هر دو ورودی‌ای پیدا کنه که هش یکسان بدن، برای همین این حمله خیلی زودتر از چیزی که در نگاه اول فکر می‌کنیم ممکن می‌شه.

https://0xkrt26.github.io/math_behind_security/2026/05/08/birthday-problem.html

@codehalics | کدهالیک

بچه‌ها گفتم شاید به درد شما هم بخوره: این اپ رو از گیت‌هاب دانلود کنین، میتونین لینک ویدئوهای یوتیوب رو از گوگل(یا هرجا) بهش بدین تا واستون با نت ملی دانلود کنه.

#اینترنت_آزاد_حق_همه_مردم

https://github.com/Kurdeus/Meli-Action

Mahdi Karbakhsh Ravari

@codehalics | کدهالیک

شکن در صورتی که ازش استفاده ناجور کنین
اکانتتون رو بن میکنه و به مراجع امنیتی ذی صلاح اطلاع میده
صرفا نوشتم که در جریان باشید ازش استفاده نکنید حتی المقدور براتون مشکلی ایجاد نشه یه وقت

@codehalics | کدهالیک