ماجرای Body در متد DELETE

امروز سعی کردم با متد DELETE داده‌ای رو به سرور ارسال کنم،ولی چون داده ها زیاد شد تصمیم گرفتم بذارم در body. اما بعد متوجه شدم که Body اصلاً دریافت نمی‌شه!
وقتی متد رو تغییر دادم، مشکل حل شد.

برای اینکه ببینم داستان این که Body با DELETE اصلاً در دسترس نیست چیه، یه سرچ کردم.
متوجه شدم که استاندارد HTTP می‌گه DELETE می‌تواند body داشته باشد. اما در عمل، سرویس‌ها و کلاینت‌ها اصلاً محل نمی‌گذارند!

یعنی عملاً ۹۹٪ سرویس‌ها و فریم‌ورک‌ها Body داخل DELETE رو نادیده می‌گیرند و اصلاً پشتیبانی نمی‌کنن. به همین دلیل استاندارد صنعت اینه که DELETE هیچ‌وقت Body نداشته باشه.

در این باره، در RFC 2616 (HTTP/1.1) هم به این موضوع اشاره شده که برای درخواست‌ها، "متد DELETE می‌تواند بدنه (Body) داشته باشد"، اما عملاً هیچ الزام یا قاعده مشخصی برای استفاده از آن وجود نداره و بسیاری از سرویس‌ها آن را نادیده می‌گیرند.

در نتیجه، اگر داده‌ای باشه که بخواهید ارسال کنید، همیشه باید اون رو در URL قرار بدید. و اگر داده‌ها زیاد شدن، بهتره از متد POST استفاده کنید.

‏ ElysiaJs یک فریمورک بر پایه ران تایم Bun هست که سرعت فوق‌العاده ای داره!

طبق بنچمارک وب سایت techempower.com می‌تونه 2 میلیون و 454 هزار ریکویست در ثانیه رو هندل کنه و در رتبه 97 قرار داره.

این در حالیه که express با 113 هزار ریکویست در ثانیه در رتبه 359 ام قرار داره!

داکیومنت خیلی تمیزی هم داره. پیشنهاد می‌کنم حتما بهش سر بزنید :
https://elysiajs.com/

یک بخش Playground هم داره که با تمرین های جالب یاد میده چطور ازش استفاده کنی.

سرگرم کننده است و میشه ازش کلی چیز یاد گرفت 👌

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

بعد از کلی فکر کردن آخرش گفت نتوانستم تغییرات لازم رو اعمال و کنم و delete ! زد کل فایل رو حذف کرد :/

متأسفانه فایل رو هم تازه ساخته بودم و track نمیشد. کلی هم روش کار کرده بودم 🤦‍♂

مشتی کد نتونستی بزنی زورت به حذف کردنش رسید؟

البته که ما زرنگ تر از این حرف هاییم،
فایل رو بازیابی کردم.

و اینبار طوره دیگه ای دستور دادم .
طوری که از کارش درس بگیره ...

به روایت تصویر 😂

پورت برنامه سرور رو گذاشته بودم روی 6000
و از کلاینت هر چقدر سعی میکردم بهش request بزنم دیدم نمیشه!
خطای کنسول رو چک کردم با این رو به رو شدم : net::ERR_UNSAFE_PORT

متوجه شدم که کروم بعضی از پورت ها رو ناامن میدونه و اونا رو بسته!
اینجا لیستی از پورت هایی که توسط کروم ناامن تشخیص داده میشن وجود داره :

https://chromium.googlesource.com/chromium/src.git/+/refs/heads/main/net/base/port_util.cc

جالب بود
AI:
مثلاً پورت ۶۰۰۰ (X11) روی لینوکس اجازه می‌ده یه برنامه به نمایشگر کاربر دسترسی پیدا کنه! اگه یه سایت بتونه بهش وصل بشه، می‌تونه اسکرین‌شات بگیره یا حتی کیبورد رو کنترل کنه (در نسخه‌های قدیمی X11).

یه آسیب پذیری فوق العاده بحرانی توی فریم ورک ری‌اکت پیدا شده که به مهاجم دسترسی اجرای کد از راه دور رو می‌ده!


نمره CVSS این آسیب پذیری 10/10 یعنی بالا ترین درجه خطر رو داره، توصیه شده فورا ری‌اکت رو آپدیت کنید.

پکیج‌هایی که آلوده‌اند:

react‑server‑dom‑webpack
react‑server‑dom‑parcel
react‑server‑dom‑turbopack

و کلی دیگر از ابزار ها درگیر شدن، توضیحات بیشتر‌...

@Linuxor

توی آپدیت جدید گوگل کروم، یک قابلیت خیلی کاربردی اضافه شده: اسپلیت کردن تب‌ها!
از این پس میشه همزمان دو تب رو در کنار هم داشت.

اگر تا به الان برای دانلود ویدیو از یوتوب و ... به هزاران سایت متوصل میشدین دیگه لازم نیست!

‏yt-dlp یک ابزار متن باز و کاربردیه که می‌تونید از طریق ترمینال فقط با کپی پیست کردن url ویدیو به راحتی دانلودش کنید که علاوه بر یوتوب کلی وب سایت دیگه رو هم پوشش میده.

داکیومنت yt-dlp برای اطلاعات بیشتر و نصب :

https://github.com/yt-dlp/yt-dlp

دوستان
عملکرد من در گیتهاب رو طی سالی که گذشت می تونید به صورت انیمیشنی ببینید

https://github.com/KEANU2003


فقط کافیه نام کاربری اکانت (مثلا KEANU2003. نیازی به لینک کامل نیست) بهش بدید تا برای شما هم یه ویدیو بسازه
https://githubunwrapped.com


#برنامه_نویسی #معرفی_سایت #گیتهاب #عملکرد_سالانه #متن_باز #رایگان #کاربردی

😂😂😂
کپشن اونقدر براش زیاده که ترجیح میدم هیچی ننویسم

🥭‏MongoDB یک روش برای دیزاین کردن اسکیما معرفی کرده که شامل چهار مرحله است :

1-حجم کاری خود را مشخص کنید
2-روابط را روی نقشه رسم کنید
3-الگوهای طراحی را اعمال کنید
4-ایندکس گذاری کنید

که الان میخوایم به اولین مرحله یعنی Identify your workload بپردازیم.

در این مرحله مشخص می‌کنیم که بیشترین عملیات هایی که در اپلیکیشن ما اغلب اجرا می‌شوند چه مواردی هستند. دانستن اینکه بیشترین query های رایج اپلیکیشن چه مواردی هستند، کمک می‌کند که ایندکس گذاری های بهتری انجام بدهیم و همچنین تعداد query هایی که به دیتابیس میزنیم کاهش یابد.

برای انجام این مرحله باید سناریو های حال حاضر اپلیکیشن و همچنین سناریو های محتمل در آینده را در نظر بگیریم. اسکیمای خود را باید طوری طراحی کنید که تمامی مراحل اپلیکیشن شما را دربر بگیرد.

دو مرحله وجود دارد :
1-تشخیص دهید که اپلیکیشن شما چه داده هایی نیاز دارد. برای گذر از این مرحله میتوانید این فاکتور ها را در نظر بگیرید :
کاربران اپلیکیشن شما و اطلاعاتی که نیاز دارند
دامنه بیزینس شما
لاگ های اپلیکیشن و query های پر تکرار

2-جدول حجم query های اپلیکیشن خود را مشخص کنید.
این جدول ستون های مشخصی دارد :
action , query type , information , frequency , priority

‏action : عملی که کاربر انجام میدهد و باعث ایجاد query میشود
‏query type : نوع query ( خواندن یا نوشتن )
‏information : فیلد های داکیومنت که یا نوشته می‌شوند یا توسط query برگردانده می‌شوند
‏frequency : برنامه از هر چند وقت یکبار query را اجرا می‌کند
‏priority : میزان اهمیت پرس‌وجو برای درخواست شما

مثال :
✅ ارسال مقاله جدید
نوع: نوشتن (Write)
داکیومنت و فیلد های تحت فشار: نویسنده، متن
محدودیت: حداکثر ۱۰ بار در روز
اولویت: بالا
—
✅ ثبت نظر روی مقاله
نوع: نوشتن (Write)
داکیومنت و فیلد های تحت فشار: کاربر، متن
محدودیت:
حداکثر ۱۰۰۰ نظر در روز
حداکثر ۱۰۰ نظر برای هر مقاله
اولویت: متوسط

—
✅ مشاهده مقاله
نوع: خواندن (Read)
داکیومنت و فیلد های تحت فشار: شناسه مقاله، متن، نظرات
محدودیت: حداکثر ۱٬۰۰۰٬۰۰۰ بار در روز
اولویت: بالا

—
✅ مشاهده آمار مقاله
نوع: خواندن (Read)
داکیومنت و فیلد های تحت فشار: شناسه مقاله، تعداد نظرات، تعداد کلیک‌ها
محدودیت: حداکثر ۱۰ بار در ساعت
اولویت: پایین

همونطور که مشاهده می‌کنید چیز پیچیده ای نیست. فقط کافیه یک چنین دیدی بر روی اپلیکیشن خودتون داشته باشید و این جدول رو برای خودتون ترسیم کنید. ( اگر در تلگرام میشد جدول ترسیم کنم بهتر می‌تونستم توضیح بدم ولی همینطوری هم خواناست (فقط اگر کمی توجه بشه ) . پس از رسم این جدول به مرحله بعدی می‌رویم : Map Schema Relationships

#MongoDB

به این چهار مرحله می‌گویند دیزاین کردن اسکیما. یعنی پس از انجام این چهار مرحله ( که الان ما مرحله یک رو با یک مثال انجام دادیم ) میتونیم اسکیما برای کالکشن مد نظر طراحی کنیم.
که زیر مجموعه Data Modeling هست. البته Data Modeling یا همین دیزاین کردن اسکیما یک فیچر در خود MongoDB نیست. همه این ها مفهوم هستند برای اینکه ما بتونیم کارمون رو بهتر پیش ببریم. وگرنه یک شخص میتونه هیچ پیش زمینه ای از این مفاهیم نداشته باشه و اسکیما مد نظر خودش رو طراحی کنه. ولی این ما هستیم که به این مفاهیم و مراحل نیاز داریم تا کار خودمون رو بهتر و اصولی تر پیش ببریم. اشخاصی که این موارد رو با اصول پیش می‌برند ، با اعتماد به نفس بیشتر ، خیال آسود تر و کیفیت بهتری کار رو انجام می‌دهند.

یک جمله طلایی :
آزادی MongoDB جایگزین تفکر مهندسی نیست

آزادی‌ای که MongoDB یا دیگر پایگاه‌های داده NoSQL به شما می‌دهند، به هیچ عنوان نباید باعث بی‌دقتی در طراحی اسکیما شود. در حالی که MongoDB از نظر ساختار داده‌ها انعطاف‌پذیر است و شما می‌توانید بدون نگرانی از محدودیت‌های مدل‌های رابطه‌ای مانند SQL کار کنید، این آزادی نباید به جواز بی‌برنامگی تبدیل شود. همچنان باید اصول مهندسی نرم‌افزار و بهترین شیوه‌ها را رعایت کنید.

سرعت افزایش تورم اگر یک زبان برنامه نویسی بود، بی‌شک در میان برنامه نویسان محبوب بود.
هرچند سینتکسش کثیف است اما performance وحشتناکی دارد.

میدونستم تقویم شمسی ( Persian calendar ) دقیق ترین تقویم جهانه. ولی نمیدونستم دقتش اینهمه از دیگر تقویم ها بیشتره!
این تقویم خطای تقریبی 1 روز از هر 110,000 هزار سال داره!
در مقایسه، تقویم میلادی خطای تقریبی 1 روز از هر 3236 داره.

توی اوج #اختلال_اینترنت اگر راهی به جز فرستادن پیامک برای ارسال کانفیگ یا آدرس دریافت #فیلترشکن نداشتین، می‌تونین پیامتون رو قبل از ارسال مخدوش و سپس بعد از دریافت به حالت عادی برگردونین.
این یه ابزار رمزگذاری و رمزگشایی ساده بصورت متن‌باز هست، که امکان اینو داره ازش فورک بگیرین و نسخه‌ی مختص خودتون رو با کمی شخصی‌سازی در الگوی رمزنگاری، پیاده کنین.
استفاده از ابزار:
https://mahdimajdian.github.io/v2ray

سورس در گیت‌هاب:
https://github.com/MahdiMajdian/v2ray

<IRCF | اینترنت آزاد برای همه>