Forwarded from دستاوردهای یادگیری عمیق(InTec)
این بار برای تست مدل یک سری تغییرات دادم :
همونطور که قبلتر هم اشاره کردم Qwen2 جزو مدلهایی هست که من همیشه ازش استفاده میکنم؛ مخصوصا روی سیستم خودم و کنار مدلهای دیگهای که دارم (multi-model)
اینبار این مدل رو با qwen2 مقایسه کردم؛ اول روی تسکهای عادی از چندساعت قبل داشتم روی یک سورس کد
نکته دوم
توی این موارد که بیشتر سرچ و توضیح بخش از کد بود و با توجه به اینکه روی
برای مثال روی مفهوم مربوط به
البته بعد از ۲-۳ بار تکرار هم زمان پاسخ
سوالات بعدی هم این موارد بود که qwen2.5 تمام موارد رو به خوبی جواب داد:
۱- سوالاتی درمورد اتفاقات اخیر انتخابات آمریکا
۲- موضوع مربوط به انفجار پیجرها و ...
۳- سخنرانی اسنودن و خلاصه صحبتش درمورد انتخابات و انتخاب رئیس جمهور
این ۳ مورد کاملا جدید بود و میشد نحوه کارش برای استخراج اطلاعات رو تست کرد؛ متاسفانه
مشکلی که با
مشکل اصلی که با
سوالات حل ریاضی - تصویر و ... هم بهش ندادم؛ چون توی کاربردهایی نیست که استفاده میکنم ولی قطعا برنده این بخش
بعد رفتم سراغ
تقریبا تمام موارد رو بدون نیاز به گوگل کردن به جواب رسیدم؛ بهترین مورد در مورد هر ۲ مدل
شدیدا منتظر انتشار مدل
دارم به این فکر میکنم شاید باید به زودی سختافزار رو برای استفاده از مدلهای
همونطور که قبلتر هم اشاره کردم Qwen2 جزو مدلهایی هست که من همیشه ازش استفاده میکنم؛ مخصوصا روی سیستم خودم و کنار مدلهای دیگهای که دارم (multi-model)
اینبار این مدل رو با qwen2 مقایسه کردم؛ اول روی تسکهای عادی از چندساعت قبل داشتم روی یک سورس کد
Rust کار میکردم؛ البته بیشتر برای یادگیری داشتم میخوندم و این ۲ مدل رو با chatgpt مقایسه کردم؛ به همه مدلها دسترسی به اینترنت دادم برای سرچ زدن و البته برای مدلهای لوکل از duckduckgo استفاده میکردم.نکته دوم
context-length مدل رو روی همون 8K نگه داشتم.توی این موارد که بیشتر سرچ و توضیح بخش از کد بود و با توجه به اینکه روی
Rust هم آموزش دیده خیلی راحت جواب میداد؛ qwen2 جاهایی رو اشتباه میزد مخصوصا وقتی مثال نزدیک بهش توی داکیومنت یا سرچ پیدا نمیکرد. اما نسخه 2.5 موردی نبود که نشه جواب بده خیلی جالب بود که وقتی مثال خوبی هم پیدا نمیکرد بر اساس توضیحات میتونست خودش مثال هم بزنه (دسترسی به سرچ رو میبستم و ازش میخواستم مثال بزنه) مدل chatgpt هم همینکار رو میکرد اما مثالهای سختتری میزد برای مثال روی مفهوم مربوط به
lifetime ازش سوال پرسیدم اما مثالی که تحویل داد ترکیبی از lifetime, generic بود و وقتی گفتم با مفهوم دوم آشنا نیستم و مثالی بزنه که فقط lifetime توی حالت خاصی که پرسیدم رو توضیح بده؛ یک مثال ساده زد که دیگه اون قوانین lifetime رو نداشت.البته بعد از ۲-۳ بار تکرار هم زمان پاسخ
chatgpt کمتر میشد هم نتایج بهبود پیدا میکرد ولی بطور کلی من امتیاز این بخش رو به qwen2.5 میدم.سوالات بعدی هم این موارد بود که qwen2.5 تمام موارد رو به خوبی جواب داد:
۱- سوالاتی درمورد اتفاقات اخیر انتخابات آمریکا
۲- موضوع مربوط به انفجار پیجرها و ...
۳- سخنرانی اسنودن و خلاصه صحبتش درمورد انتخابات و انتخاب رئیس جمهور
این ۳ مورد کاملا جدید بود و میشد نحوه کارش برای استخراج اطلاعات رو تست کرد؛ متاسفانه
chatgpt کمی با احتیاط پاسخ میداد (یک سری سوالات جزئی دیگر هم پرسیدم که مجبورش کنم جواب دقیقتر و بیپرده بده ولی با اینکه با توجه به factها باید یک طرف رو انتخاب میکرد اینکار رو نکرد)مشکلی که با
qwen2.5 نبود و راحت تر میشد ازش جواب بر اساس دیتا گرفت (البته این مدل هم سانسور شده هست ولی به سوالات عمومی بر اساس دیتا راحتتر جواب میده)مشکل اصلی که با
qwen2.5 روی سوالات بالا داشتم کم بودن context-length بود؛ چون گزارش شده بود که مدل 32 میلیارد پارامتری عملکرد بهتری از chatgpt 4o-mini داره برای همین منم از 32b استفاده کردم بجای 7b و مجبور شدم روی 8K context بمونم.سوالات حل ریاضی - تصویر و ... هم بهش ندادم؛ چون توی کاربردهایی نیست که استفاده میکنم ولی قطعا برنده این بخش
chatgpt o1 خواهد بود بدون شک.بعد رفتم سراغ
qwen2.5-coder فعلا فقط مدل 7b منتشر شده؛ و منم مستقیم رفتم سر وقت باگهایی که توی کدهای Rust داشتم میگرفتم؛ خیلی سوالاتم سخت و پیچیده نبود شاید (چون تازهکار هستم توی Rust و نمیتونم ارزیابی کنم سطح کدها رو) و تمام موارد رو با روش ۵ مرحلهای که چندشب پیش گفتم ارزیابی کردم.تقریبا تمام موارد رو بدون نیاز به گوگل کردن به جواب رسیدم؛ بهترین مورد در مورد هر ۲ مدل
qwen2.5, qwen2.5-coder قدرتشون توی دنبال کردن دستورالعملها بود.شدیدا منتظر انتشار مدل
qwen2.5-coder 32b هستم برای استفاده روزمره.دارم به این فکر میکنم شاید باید به زودی سختافزار رو برای استفاده از مدلهای
70b آپگرید کنم 🧐Forwarded from ASafaeirad
React 19 Cheat Sheet
by Kent C. Dodds
https://res.cloudinary.com/epic-web/image/upload/v1725974609/react-19-cheat-sheet.pdf
#react
by Kent C. Dodds
https://res.cloudinary.com/epic-web/image/upload/v1725974609/react-19-cheat-sheet.pdf
#react
Forwarded from Laravel News
Fetch PHP is a Lightweight HTTP Library Inspired by JavaScript's fetch() https://laravel-news.com/fetch-php
Laravel News
Fetch PHP is a Lightweight HTTP Library Inspired by JavaScript's fetch() - Laravel News
Fetch PHP is a lightweight HTTP library inspired by JavaScript's fetch, bringing simplicity and flexibility to PHP HTTP requests.
Forwarded from linuxtnt(linux tips and tricks) (hosein seilany https://seilany.ir/)
دستوراتی برای مدیران سیستم لینوکس:
برای پشتیبان گیری از grub
برای بازیابی از grub
نویسنده: حسین سیلانی
منبع : کانال لینوکسی: لینوکس تی ان تی
@linuxtnt
https://seilany.ir
برای پشتیبان گیری از grub
sudo dd if=/dev/sd1 of=/mbr_backup.img bs=512 count=1
برای بازیابی از grub
sudo dd if=/mbr_backup.img of=/dev/sda bs=512 count=1
نویسنده: حسین سیلانی
منبع : کانال لینوکسی: لینوکس تی ان تی
@linuxtnt
https://seilany.ir
Forwarded from linuxtnt(linux tips and tricks) (hosein seilany https://seilany.ir/)
در نسخه 6.12 لینوکس، امکان نمایش کد QR در هنگام وقوع کرنل پنیک به صورت اختیاری اضافه شده است.
این ویژگی از طریق زیرساخت مدیریت خطای DRM Panic اضافه شده و در اواسط سپتامبر به هسته لینوکس اضافه خواهد شد.
این قابلیت به کاربران اجازه میدهد تا در صورت وقوع خطای “صفحه مرگ” در DRM، یک کد QR نمایش داده شود. این کد QR میتواند اطلاعات زیادی را که ممکن است در خروجی متنی ساده به سختی قابل دریافت باشد، به صورت کاربرپسندتری نمایش دهد.
این ویژگی با زبان برنامهنویسی Rust نوشته شده و برای استفاده از آن باید ساخت هسته با پشتیبانی از Rust فعال باشد. همچنین، این قابلیت توسط سوئیچ ساخت Kconfig به نام DRM_PANIC_SCREEN_QR_CODE کنترل میشود و امکان تنظیم URL پایه کد QR و نسخه کد QR برای مقدار دادههای اشکالزدایی که میتوان ذخیره کرد، وجود دارد.
——————-
نویسنده: حسین سیلانی
منبع : کانال لینوکسی: لینوکس تی ان تی
@linuxtnt
https://seilany.ir
این ویژگی از طریق زیرساخت مدیریت خطای DRM Panic اضافه شده و در اواسط سپتامبر به هسته لینوکس اضافه خواهد شد.
این قابلیت به کاربران اجازه میدهد تا در صورت وقوع خطای “صفحه مرگ” در DRM، یک کد QR نمایش داده شود. این کد QR میتواند اطلاعات زیادی را که ممکن است در خروجی متنی ساده به سختی قابل دریافت باشد، به صورت کاربرپسندتری نمایش دهد.
این ویژگی با زبان برنامهنویسی Rust نوشته شده و برای استفاده از آن باید ساخت هسته با پشتیبانی از Rust فعال باشد. همچنین، این قابلیت توسط سوئیچ ساخت Kconfig به نام DRM_PANIC_SCREEN_QR_CODE کنترل میشود و امکان تنظیم URL پایه کد QR و نسخه کد QR برای مقدار دادههای اشکالزدایی که میتوان ذخیره کرد، وجود دارد.
——————-
نویسنده: حسین سیلانی
منبع : کانال لینوکسی: لینوکس تی ان تی
@linuxtnt
https://seilany.ir
Forwarded from Ninja Learn | نینجا لرن
📕 کتاب REST API Design Rulebook
📌 فصل سوم: Interaction Design with HTTP
📍پارت: دوم
#کتاب
💎 استاتوس کدهای ریسپانس (Response Status Codes) 💎
REST API ها از قسمت Status-Line توی ریسپانس HTTP استفاده میکنن تا به کلاینتها نتیجه درخواستشون رو اعلام کنن. استاندارد RFC 2616، ساختار Status-Line رو به این شکل تعریف کرده:
HTTP حدود ۴۰ تا کد وضعیت استاندارد داره که برای بیان نتیجه درخواستهای کلاینت استفاده میشه. این کدها به ۵ دسته اصلی تقسیم میشن که توی جدول زیر توضیح دادم:
⭕️ دستهبندی کدهای وضعیت:
⭕️ قوانین استفاده از کدهای وضعیت:
⭕️ کد 200 (OK): برای موفقیت کلی
این کد معمولاً همون چیزیه که کلاینت انتظار داره ببینه. یعنی درخواست با موفقیت انجام شده و نیازی به استفاده از کد خاص دیگهای از سری ۲xx نیست. برعکس کد 204، وقتی 200 برگرده، باید یه بدنه پاسخ (response body) هم داشته باشه.
⭕️ کد 200 (OK) نباید برای اعلام خطا استفاده بشه
همیشه باید از کدهای وضعیت HTTP درست استفاده کنید. بهخصوص، نباید برای سازگار شدن با کلاینتهای سادهتر از قواعد استاندارد API صرفنظر کرد.
⭕️ کد 201 (Created): برای ایجاد موفقیتآمیز منابع جدید
هر وقت که یه API یه منبع جدید برای درخواست کلاینت ایجاد میکنه (مثلاً توی یه کالکشن یا فروشگاه)، باید از کد 201 استفاده کنه. حتی اگر منبع جدید از طریق یه عمل کنترلر ایجاد بشه، باز هم 201 کد درستی برای پاسخ هست.
⭕️ کد 202 ("Accepted") باید برای شروع موفقیتآمیز یک عملیات غیرهمزمان استفاده بشه
کد 202 یعنی درخواست کلاینت قراره به صورت غیرهمزمان (آسنکرون) پردازش بشه. این کد به کلاینت میگه که درخواستش معتبر به نظر میرسه، اما ممکنه بعداً موقع پردازش به مشکل بخوره. این کد معمولاً برای عملیاتهایی که زمان زیادی میبرن استفاده میشه.
کنترلرها میتونن 202 رو برگردونن، اما منابع دیگه نباید این کار رو بکنن.
⭕️ کد 204 ("No Content") باید زمانی استفاده بشه که بدنه پاسخ (response body) خالیه
کد 204 معمولاً وقتی استفاده میشه که API به درخواستهای PUT، POST یا DELETE پاسخ میده ولی قصد نداره که توی پاسخ، پیام یا دادهای برگردونه.
حتی در پاسخ به درخواست GET هم میشه از 204 استفاده کرد تا بگه منبع درخواستشده وجود داره، ولی چیزی برای نمایش نداره.
⭕️ کد 301 ("Moved Permanently") برای تغییر مکان دائمی منابع استفاده بشه
- کد 301 وقتی استفاده میشه که مدل منابع توی API تغییر بزرگی کرده و یه آدرس جدید برای منبع به کلاینت اختصاص داده شده. توی این حالت، آدرس جدید باید توی هدر "Location" به کلاینت اعلام بشه.
⭕️ از کد 302 ("Found") نباید استفاده بشه
کد 302 همیشه اشتباه فهمیده شده و برنامهنویسا توی پیادهسازیش اشتباه کردن. مشکل اصلی اینجاست که کلاینتها بهطور خودکار برای آدرس جدید یه درخواست GET میفرستن، حتی اگر روش اصلی درخواست چیز دیگهای بوده.
برای رفع این مشکل، توی HTTP 1.1 کدهای 303 ("See Other") و 307 ("Temporary Redirect") معرفی شدن که به جای 302 باید استفاده بشن.
⭕️ کد 303 ("See Other") باید برای ارجاع کلاینت به یه URI دیگه استفاده بشه
وقتی یه کنترلر کارش رو تموم کرده، به جای فرستادن پاسخ توی بدنهای که شاید کلاینت نمیخواد، میتونه با کد 303 یه URI جدید به کلاینت بده. این URI میتونه به یه پیام موقت یا یه منبع دائمیتر اشاره کنه.
این کد به API اجازه میده که به جای تحمیل دانلود اطلاعات به کلاینت، یه مرجع به منبع بده و کلاینت اگه بخواد میتونه با GET به URI جدید دسترسی پیدا کنه.
⭕️ کد 304 ("Not Modified") باید برای صرفهجویی در پهنای باند استفاده بشه
این کد شبیه کد 204 ("No Content") هست چون هیچ چیزی توی بدنه پاسخ نیست، اما تفاوت اصلی اینه که 204 وقتی استفاده میشه که هیچ دادهای برای فرستادن وجود نداره، ولی 304 وقتی استفاده میشه که منبع اطلاعات داره اما کلاینت قبلاً آخرین نسخهاش رو گرفته.
این کد بیشتر توی درخواستهای HTTP شرطی (conditional requests) کاربرد داره.
@ninja_learn_ir
📌 فصل سوم: Interaction Design with HTTP
📍پارت: دوم
#کتاب
💎 استاتوس کدهای ریسپانس (Response Status Codes) 💎
REST API ها از قسمت Status-Line توی ریسپانس HTTP استفاده میکنن تا به کلاینتها نتیجه درخواستشون رو اعلام کنن. استاندارد RFC 2616، ساختار Status-Line رو به این شکل تعریف کرده:
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
HTTP حدود ۴۰ تا کد وضعیت استاندارد داره که برای بیان نتیجه درخواستهای کلاینت استفاده میشه. این کدها به ۵ دسته اصلی تقسیم میشن که توی جدول زیر توضیح دادم:
⭕️ دستهبندی کدهای وضعیت:
1. 1xx: اطلاعاتی – اطلاعاتی در مورد سطح پروتکل انتقال میده.
2. 2xx: موفقیتآمیز – درخواست کلاینت با موفقیت قبول شده.
3. 3xx: تغییر مسیر – کلاینت باید یه کار اضافی انجام بده تا درخواست کامل بشه.
4. 4xx: خطای کلاینت – خطاهای این دسته مربوط به اشتباهات کلاینت هست.
5. 5xx: خطای سرور – سرور مسئولیت این خطاها رو قبول میکنه.
⭕️ قوانین استفاده از کدهای وضعیت:
⭕️ کد 200 (OK): برای موفقیت کلی
این کد معمولاً همون چیزیه که کلاینت انتظار داره ببینه. یعنی درخواست با موفقیت انجام شده و نیازی به استفاده از کد خاص دیگهای از سری ۲xx نیست. برعکس کد 204، وقتی 200 برگرده، باید یه بدنه پاسخ (response body) هم داشته باشه.
⭕️ کد 200 (OK) نباید برای اعلام خطا استفاده بشه
همیشه باید از کدهای وضعیت HTTP درست استفاده کنید. بهخصوص، نباید برای سازگار شدن با کلاینتهای سادهتر از قواعد استاندارد API صرفنظر کرد.
⭕️ کد 201 (Created): برای ایجاد موفقیتآمیز منابع جدید
هر وقت که یه API یه منبع جدید برای درخواست کلاینت ایجاد میکنه (مثلاً توی یه کالکشن یا فروشگاه)، باید از کد 201 استفاده کنه. حتی اگر منبع جدید از طریق یه عمل کنترلر ایجاد بشه، باز هم 201 کد درستی برای پاسخ هست.
⭕️ کد 202 ("Accepted") باید برای شروع موفقیتآمیز یک عملیات غیرهمزمان استفاده بشه
کد 202 یعنی درخواست کلاینت قراره به صورت غیرهمزمان (آسنکرون) پردازش بشه. این کد به کلاینت میگه که درخواستش معتبر به نظر میرسه، اما ممکنه بعداً موقع پردازش به مشکل بخوره. این کد معمولاً برای عملیاتهایی که زمان زیادی میبرن استفاده میشه.
کنترلرها میتونن 202 رو برگردونن، اما منابع دیگه نباید این کار رو بکنن.
⭕️ کد 204 ("No Content") باید زمانی استفاده بشه که بدنه پاسخ (response body) خالیه
کد 204 معمولاً وقتی استفاده میشه که API به درخواستهای PUT، POST یا DELETE پاسخ میده ولی قصد نداره که توی پاسخ، پیام یا دادهای برگردونه.
حتی در پاسخ به درخواست GET هم میشه از 204 استفاده کرد تا بگه منبع درخواستشده وجود داره، ولی چیزی برای نمایش نداره.
⭕️ کد 301 ("Moved Permanently") برای تغییر مکان دائمی منابع استفاده بشه
- کد 301 وقتی استفاده میشه که مدل منابع توی API تغییر بزرگی کرده و یه آدرس جدید برای منبع به کلاینت اختصاص داده شده. توی این حالت، آدرس جدید باید توی هدر "Location" به کلاینت اعلام بشه.
⭕️ از کد 302 ("Found") نباید استفاده بشه
کد 302 همیشه اشتباه فهمیده شده و برنامهنویسا توی پیادهسازیش اشتباه کردن. مشکل اصلی اینجاست که کلاینتها بهطور خودکار برای آدرس جدید یه درخواست GET میفرستن، حتی اگر روش اصلی درخواست چیز دیگهای بوده.
برای رفع این مشکل، توی HTTP 1.1 کدهای 303 ("See Other") و 307 ("Temporary Redirect") معرفی شدن که به جای 302 باید استفاده بشن.
⭕️ کد 303 ("See Other") باید برای ارجاع کلاینت به یه URI دیگه استفاده بشه
وقتی یه کنترلر کارش رو تموم کرده، به جای فرستادن پاسخ توی بدنهای که شاید کلاینت نمیخواد، میتونه با کد 303 یه URI جدید به کلاینت بده. این URI میتونه به یه پیام موقت یا یه منبع دائمیتر اشاره کنه.
این کد به API اجازه میده که به جای تحمیل دانلود اطلاعات به کلاینت، یه مرجع به منبع بده و کلاینت اگه بخواد میتونه با GET به URI جدید دسترسی پیدا کنه.
⭕️ کد 304 ("Not Modified") باید برای صرفهجویی در پهنای باند استفاده بشه
این کد شبیه کد 204 ("No Content") هست چون هیچ چیزی توی بدنه پاسخ نیست، اما تفاوت اصلی اینه که 204 وقتی استفاده میشه که هیچ دادهای برای فرستادن وجود نداره، ولی 304 وقتی استفاده میشه که منبع اطلاعات داره اما کلاینت قبلاً آخرین نسخهاش رو گرفته.
این کد بیشتر توی درخواستهای HTTP شرطی (conditional requests) کاربرد داره.
@ninja_learn_ir
Forwarded from Ninja Learn | نینجا لرن
⭕️ کد 307 ("Temporary Redirect") برای تغییر موقتی مکان درخواست کلاینت استفاده بشه
- HTTP/1.1 کد 307 رو معرفی کرد تا کاربرد درست کد 302 ("Found") رو مشخص کنه. وقتی کد 307 برگرده، یعنی API قراره درخواست رو پردازش نکنه و کلاینت باید درخواستش رو به یه URI دیگه که توی هدر "Location" داده شده، بفرسته.
- این کد معمولاً برای اختصاص یه آدرس موقت به درخواست منبع استفاده میشه. مثلاً میشه درخواست رو به یه سرور دیگه انتقال داد.
⭕️ کد 400 ("Bad Request") برای اعلام شکست عمومی درخواست کلاینت استفاده بشه
کد 400 یه خطای کلی سمت کلاینت هست و زمانی استفاده میشه که هیچ کد دیگهای از سری 4xx مناسب نباشه.
⭕️ کد 401 ("Unauthorized") باید زمانی استفاده بشه که مشکلی با اعتبارسنجی کلاینت وجود داره
این کد یعنی کلاینت سعی کرده به یه منبع محافظتشده دسترسی پیدا کنه ولی اعتبارنامه مناسب ارائه نداده. ممکنه اعتبارنامهها اشتباه باشن یا اصلاً وجود نداشته باشن.
⭕️ کد 403 ("Forbidden") باید زمانی استفاده بشه که دسترسی به منبع غیرممکنه، فارغ از وضعیت اعتبارسنجی
- این کد یعنی درخواست کلاینت درسته ولی API اجازه انجامش رو نمیده. این موضوع ربطی به مشکل اعتبارنامهها نداره (اون مورد 401 هست).
- APIهای REST از 403 برای مدیریت سطح دسترسیها استفاده میکنن. مثلاً ممکنه یه کلاینت اجازه دسترسی به بعضی منابع رو داشته باشه ولی نه به همه. اگه کلاینت سعی کنه خارج از محدوده مجازش به منبعی دسترسی پیدا کنه، API باید با 403 پاسخ بده.
⭕️ کد 404 ("Not Found") باید زمانی استفاده بشه که URI کلاینت به منبعی مرتبط نمیشه
کد 404 یعنی API نمیتونه URI درخواستشده رو به منبعی متصل کنه.
⭕️ کد 405 ("Method Not Allowed") باید زمانی استفاده بشه که روش HTTP پشتیبانی نمیشه
- API با کد 405 پاسخ میده تا به کلاینت بگه که از روشی استفاده کرده که برای اون منبع مجاز نیست. مثلاً یه منبع فقط قابل خواندن ممکنه فقط GET و HEAD رو پشتیبانی کنه، ولی یه کنترلر ممکنه GET و POST رو مجاز بدونه اما PUT یا DELETE رو نه.
- پاسخ 405 باید شامل هدر "Allow" باشه که روشهای مجاز برای اون منبع رو لیست کنه. مثلاً:
⭕️ کد 406 ("Not Acceptable") باید زمانی استفاده بشه که نوع دادهای که کلاینت درخواست داده قابل سرویسدهی نیست
- کد 406 یعنی API نمیتونه نوع مدیا (media type) درخواستی کلاینت رو ایجاد کنه. مثلاً اگه کلاینت درخواست داده به فرمت application/xml بده و API فقط با application/json کار کنه، کد 406 برمیگرده.
⭕️ کد 409 ("Conflict") باید زمانی استفاده بشه که درخواست کلاینت باعث نقض وضعیت منبع بشه
- کد 409 به کلاینت میگه که درخواستش باعث شده منبع API توی حالت ناسازگار یا غیرممکن قرار بگیره. مثلاً اگه کلاینت بخواد یه منبع پرشده رو حذف کنه و اون منبع هنوز داده داره، ممکنه API با 409 پاسخ بده.
⭕️ کد 412 ("Precondition Failed") باید برای پشتیبانی از عملیاتهای شرطی استفاده بشه
- این کد یعنی کلاینت یه سری شرایط رو توی هدر درخواستش مشخص کرده و به API گفته که فقط اگه اون شرایط برقرار باشه درخواستش رو انجام بده. اگه شرایط محقق نشه، API با کد 412 پاسخ میده.
⭕️ کد 415 ("Unsupported Media Type") باید زمانی استفاده بشه که نوع مدیا در payload درخواست قابل پردازش نباشه
- این کد یعنی API نمیتونه نوع مدیایی که کلاینت فرستاده رو پردازش کنه. مثلاً اگه کلاینت دادهها رو به فرمت application/xml بفرسته ولی API فقط با application/json کار کنه، کد 415 برگردونده میشه.
⭕️ کد 500 ("Internal Server Error") باید برای اعلام مشکل داخلی API استفاده بشه
- کد 500 یه خطای عمومی API هست که بیشتر فریمورکهای وب خودکار این کد رو برمیگردونن وقتی که درخواست کلاینت باعث ایجاد یه استثنا توی کد بشه.
- این خطا تقصیر کلاینت نیست، پس کلاینت میتونه همون درخواست رو دوباره امتحان کنه و امید داشته باشه که نتیجه متفاوتی بگیره.
@ninja_learn_ir
- HTTP/1.1 کد 307 رو معرفی کرد تا کاربرد درست کد 302 ("Found") رو مشخص کنه. وقتی کد 307 برگرده، یعنی API قراره درخواست رو پردازش نکنه و کلاینت باید درخواستش رو به یه URI دیگه که توی هدر "Location" داده شده، بفرسته.
- این کد معمولاً برای اختصاص یه آدرس موقت به درخواست منبع استفاده میشه. مثلاً میشه درخواست رو به یه سرور دیگه انتقال داد.
⭕️ کد 400 ("Bad Request") برای اعلام شکست عمومی درخواست کلاینت استفاده بشه
کد 400 یه خطای کلی سمت کلاینت هست و زمانی استفاده میشه که هیچ کد دیگهای از سری 4xx مناسب نباشه.
⭕️ کد 401 ("Unauthorized") باید زمانی استفاده بشه که مشکلی با اعتبارسنجی کلاینت وجود داره
این کد یعنی کلاینت سعی کرده به یه منبع محافظتشده دسترسی پیدا کنه ولی اعتبارنامه مناسب ارائه نداده. ممکنه اعتبارنامهها اشتباه باشن یا اصلاً وجود نداشته باشن.
⭕️ کد 403 ("Forbidden") باید زمانی استفاده بشه که دسترسی به منبع غیرممکنه، فارغ از وضعیت اعتبارسنجی
- این کد یعنی درخواست کلاینت درسته ولی API اجازه انجامش رو نمیده. این موضوع ربطی به مشکل اعتبارنامهها نداره (اون مورد 401 هست).
- APIهای REST از 403 برای مدیریت سطح دسترسیها استفاده میکنن. مثلاً ممکنه یه کلاینت اجازه دسترسی به بعضی منابع رو داشته باشه ولی نه به همه. اگه کلاینت سعی کنه خارج از محدوده مجازش به منبعی دسترسی پیدا کنه، API باید با 403 پاسخ بده.
⭕️ کد 404 ("Not Found") باید زمانی استفاده بشه که URI کلاینت به منبعی مرتبط نمیشه
کد 404 یعنی API نمیتونه URI درخواستشده رو به منبعی متصل کنه.
⭕️ کد 405 ("Method Not Allowed") باید زمانی استفاده بشه که روش HTTP پشتیبانی نمیشه
- API با کد 405 پاسخ میده تا به کلاینت بگه که از روشی استفاده کرده که برای اون منبع مجاز نیست. مثلاً یه منبع فقط قابل خواندن ممکنه فقط GET و HEAD رو پشتیبانی کنه، ولی یه کنترلر ممکنه GET و POST رو مجاز بدونه اما PUT یا DELETE رو نه.
- پاسخ 405 باید شامل هدر "Allow" باشه که روشهای مجاز برای اون منبع رو لیست کنه. مثلاً:
Allow: GET, POST
⭕️ کد 406 ("Not Acceptable") باید زمانی استفاده بشه که نوع دادهای که کلاینت درخواست داده قابل سرویسدهی نیست
- کد 406 یعنی API نمیتونه نوع مدیا (media type) درخواستی کلاینت رو ایجاد کنه. مثلاً اگه کلاینت درخواست داده به فرمت application/xml بده و API فقط با application/json کار کنه، کد 406 برمیگرده.
⭕️ کد 409 ("Conflict") باید زمانی استفاده بشه که درخواست کلاینت باعث نقض وضعیت منبع بشه
- کد 409 به کلاینت میگه که درخواستش باعث شده منبع API توی حالت ناسازگار یا غیرممکن قرار بگیره. مثلاً اگه کلاینت بخواد یه منبع پرشده رو حذف کنه و اون منبع هنوز داده داره، ممکنه API با 409 پاسخ بده.
⭕️ کد 412 ("Precondition Failed") باید برای پشتیبانی از عملیاتهای شرطی استفاده بشه
- این کد یعنی کلاینت یه سری شرایط رو توی هدر درخواستش مشخص کرده و به API گفته که فقط اگه اون شرایط برقرار باشه درخواستش رو انجام بده. اگه شرایط محقق نشه، API با کد 412 پاسخ میده.
⭕️ کد 415 ("Unsupported Media Type") باید زمانی استفاده بشه که نوع مدیا در payload درخواست قابل پردازش نباشه
- این کد یعنی API نمیتونه نوع مدیایی که کلاینت فرستاده رو پردازش کنه. مثلاً اگه کلاینت دادهها رو به فرمت application/xml بفرسته ولی API فقط با application/json کار کنه، کد 415 برگردونده میشه.
⭕️ کد 500 ("Internal Server Error") باید برای اعلام مشکل داخلی API استفاده بشه
- کد 500 یه خطای عمومی API هست که بیشتر فریمورکهای وب خودکار این کد رو برمیگردونن وقتی که درخواست کلاینت باعث ایجاد یه استثنا توی کد بشه.
- این خطا تقصیر کلاینت نیست، پس کلاینت میتونه همون درخواست رو دوباره امتحان کنه و امید داشته باشه که نتیجه متفاوتی بگیره.
@ninja_learn_ir
Forwarded from DevTwitter | توییت برنامه نویسی
یه بازی خیلی ساده تحت وب ساختم که بهت اسکرین شات بازیهای مختلف رو نمایش میده و باید عنوان بازی رو حدس بزنی.
هنوز کامل نیست. یعنی فقط ۲۰ تا بازی رو پوشش میده و دسته بندی ها کارکرد ندارن.
اگه دوست داشتی تست بزن.
دم شما گرم.
bardialatifi.github.io/Guessing-Game/
@DevTwitter | <Bear The Yara/>
هنوز کامل نیست. یعنی فقط ۲۰ تا بازی رو پوشش میده و دسته بندی ها کارکرد ندارن.
اگه دوست داشتی تست بزن.
دم شما گرم.
bardialatifi.github.io/Guessing-Game/
@DevTwitter | <Bear The Yara/>
Forwarded from DevAcademy
اون روزهایی که تازه داشتم React یاد میگرفتم خیلی سر درگم بودم و دنبال منابع خوب میگشتم!
به مرور از جاهای مختلف به یک سری newsletterهای مشتی دسترسی پیدا کردم و الان هر هفته کلی مقاله جذاب و جدید به دستم میرسه که باعث پیشرفت سریعترم میشن.
حالا که دارم Vue.js رو یاد میگیرم، میخوام این گنجینه رو به شما انتقال بدم. یه عالمه نیوزلتر خوب که مطمئنم بهتون کمک میکنه. میتونید برید موضوع هر newsletter رو ببینید و هرکدوم رو که دوست داشتید subscribe کنین.
بعضی از newsletterهای جذابی که دارم:
React Digest: یه گنجینهی واقعی از مقالات
https://reactdigest.net/
Kent C. Dodds: این آقا یه نابغه است و بلاگش پر از نکات کاربردیه.
https://lnkd.in/dVR4sTH9
This Week in React: هر هفته خلاصهای از مهمترین اخبار React رو براتون میفرسته.
https://lnkd.in/dny5aBdU
Large Apps: برای ساختن اپلیکیشنهای بزرگ، این newsletter عالیه.
https://lnkd.in/dArS4VK3
The T-Shaped Dev: اگه میخواید توسعهدهندهی همه کاره بشید، این newsletter رو از دست ندید.
https://lnkd.in/dzipuC9r
Daily.dev: یه پلتفرم جامع برای developerهاست که هر روز مقالههای جدید داره.
https://app.daily.dev/
Craft Better Software: برای اونایی که به تست نویسی علاقه دارن، این newsletter فوقالعادست.
https://lnkd.in/dPseSv4V
Cassidoo: یه newsletter فان و خندهدار با کلی نکتهی کاربردی.
https://lnkd.in/dBGGgfFW
System Design: اگه به معماری سیستم علاقهمندید، این newsletter براتون جذابه.
https://lnkd.in/d6gZXeqX
The Hustling Engineer: برای مهندسهایی که میخوان حرفه خودشون رو ارتقا بدن.
https://lnkd.in/dPWEsFgS
https://www.linkedin.com/posts/reihaneh-sadat-shokouhi-78b22a233_%D8%B3%D9%84%D8%A7%D9%85-%D8%A8%DA%86%D9%87%D9%87%D8%A7-%D8%A7%D9%85%D8%B1%D9%88%D8%B2-%D8%A8%D8%A7-%D8%AF%D8%B3%D8%AA-%D9%BE%D8%B1-%D8%A7%D9%88%D9%85%D8%AF%D9%85-%D8%A7%D9%88%D9%86-%D8%B1%D9%88%D8%B2%D9%87%D8%A7%DB%8C%DB%8C-activity-7241657143618088964-57Wm?utm_source=share&utm_medium=member_desktop
💻@DevAcaademy
💬@DevAcademyGroup
به مرور از جاهای مختلف به یک سری newsletterهای مشتی دسترسی پیدا کردم و الان هر هفته کلی مقاله جذاب و جدید به دستم میرسه که باعث پیشرفت سریعترم میشن.
حالا که دارم Vue.js رو یاد میگیرم، میخوام این گنجینه رو به شما انتقال بدم. یه عالمه نیوزلتر خوب که مطمئنم بهتون کمک میکنه. میتونید برید موضوع هر newsletter رو ببینید و هرکدوم رو که دوست داشتید subscribe کنین.
بعضی از newsletterهای جذابی که دارم:
React Digest: یه گنجینهی واقعی از مقالات
https://reactdigest.net/
Kent C. Dodds: این آقا یه نابغه است و بلاگش پر از نکات کاربردیه.
https://lnkd.in/dVR4sTH9
This Week in React: هر هفته خلاصهای از مهمترین اخبار React رو براتون میفرسته.
https://lnkd.in/dny5aBdU
Large Apps: برای ساختن اپلیکیشنهای بزرگ، این newsletter عالیه.
https://lnkd.in/dArS4VK3
The T-Shaped Dev: اگه میخواید توسعهدهندهی همه کاره بشید، این newsletter رو از دست ندید.
https://lnkd.in/dzipuC9r
Daily.dev: یه پلتفرم جامع برای developerهاست که هر روز مقالههای جدید داره.
https://app.daily.dev/
Craft Better Software: برای اونایی که به تست نویسی علاقه دارن، این newsletter فوقالعادست.
https://lnkd.in/dPseSv4V
Cassidoo: یه newsletter فان و خندهدار با کلی نکتهی کاربردی.
https://lnkd.in/dBGGgfFW
System Design: اگه به معماری سیستم علاقهمندید، این newsletter براتون جذابه.
https://lnkd.in/d6gZXeqX
The Hustling Engineer: برای مهندسهایی که میخوان حرفه خودشون رو ارتقا بدن.
https://lnkd.in/dPWEsFgS
https://www.linkedin.com/posts/reihaneh-sadat-shokouhi-78b22a233_%D8%B3%D9%84%D8%A7%D9%85-%D8%A8%DA%86%D9%87%D9%87%D8%A7-%D8%A7%D9%85%D8%B1%D9%88%D8%B2-%D8%A8%D8%A7-%D8%AF%D8%B3%D8%AA-%D9%BE%D8%B1-%D8%A7%D9%88%D9%85%D8%AF%D9%85-%D8%A7%D9%88%D9%86-%D8%B1%D9%88%D8%B2%D9%87%D8%A7%DB%8C%DB%8C-activity-7241657143618088964-57Wm?utm_source=share&utm_medium=member_desktop
💻@DevAcaademy
💬@DevAcademyGroup
reactdigest.net
React Digest: Email Newsletter
React Digest is a free curated weekly newsletter for React developers that want to improve their skills and keep up to date with JavaScript.
Forwarded from Anophel | آنوفل
آشنایی با Error Handling در Go : بررسی عمیق
🔺 مدیریت خطا (Error Handling) یک جنبه حیاتی در هر زبان برنامه نویسی است و Go نیز از این قاعده مستثنی نیست. در این مقاله از سری مقالات گولنگ در آنوفل، به بررسی اشتباهات معمولی که حتی توسعه دهندگان باتجربه مرتکب می شوند اختصاص یافته است، ما بر Error Hand...
🌐 : آشنایی با Error Handling در Go : بررسی عمیق
🔺 مدیریت خطا (Error Handling) یک جنبه حیاتی در هر زبان برنامه نویسی است و Go نیز از این قاعده مستثنی نیست. در این مقاله از سری مقالات گولنگ در آنوفل، به بررسی اشتباهات معمولی که حتی توسعه دهندگان باتجربه مرتکب می شوند اختصاص یافته است، ما بر Error Hand...
🌐 : آشنایی با Error Handling در Go : بررسی عمیق
Forwarded from Web Application Security
یه آسیب پذیری ظاهرا بی ارزش =
کد زیر رو در نظر بگیرین:
سناریو اینه که این فایل مربوط به یکی از فایل های پنل ادمینه که طبیعتا باید فقط ادمین دسترسی داشته باشه، از داخل sessionی که برای هر کاربر ست کرده چک میکنه ببینه اگه سطح دسترسی ای که به این کاربر داده ادمین نبود redirect کنه به صفحه home.
مشکلی که تو این کد هست اینه که درسته redirect میکنه ولی جلوی اجرا شدن کد رو نمیگیره بعد redirect و باعث میشه مابقی کد هم اجرا بشن بعد redirect. ولی چه تهدیدی داره؟
1⃣ افشا شدن response بعد از redirect :
اگه با دستور زیر به اون مسیر curl بزنیم میتونیم کل ریسپانس رو ببینیم:
نکته : ما فقط میتونیم response رو ببینیم نه سورس کد اپلیکیشن. ممکنه برنامه نویس از توابعی استفاده کرده باشه که اطلاعات مهمی رو روی صفحه چاپ کنه مثل echo. برای درک بهتر کد زیر رو در نظر بگیرید :
2⃣ تست آسیب پذیری های مختلف!
کد زیر رو در نظر بگیرین:
آسیب پذیری ای که این کد داره Command Injectionهست. ولی نکته ای که مهمه اینه که این صفحه چون redirect میکنه خیلیا اینجا parameter fuzz انجام نمیدن و آسیب پذیری های این صفحه فقط با دسترسی ادمین قابل دیدن و تست کردنه، ولی بخاطر اشتباه برنامه نویس مهاجم میتونه parameter fuzz انجام بده و آسیب پذیری های مختلفی رو تست کنه که بسته به logic برنامه ممکنه آسیب پذیری های مختلفی رو داشته باشه. اگه باگ هانترین حتما به این نکته توجه داشته باشین موقع مواجه شدن با redirect ها.
نمونه پیلود با curl برای تست آسیب پذیری :
نکته مهم : کد های نوشته شده با php رو اگه تو سیستمتون اجرا کنین به درستی کار نمیکنن چون باید خودتون session کاربر رو ست کنین.
⁉️روش جلوگیری چیه؟
بعد redirect باید جلوی اجرا شدن ادامه کد رو بگیریم که میتونیم با توابع زیر انجام بدیم:
اسم آسیب پذیری :
Execution After Redirect = EAR
#EAR
#parameter_fuzz
کد زیر رو در نظر بگیرین:
<?php
session_start();
if($_SESSION['is_admin'] != true)
{
header("Location: /home.php");
}
// Application code is here
?>
سناریو اینه که این فایل مربوط به یکی از فایل های پنل ادمینه که طبیعتا باید فقط ادمین دسترسی داشته باشه، از داخل sessionی که برای هر کاربر ست کرده چک میکنه ببینه اگه سطح دسترسی ای که به این کاربر داده ادمین نبود redirect کنه به صفحه home.
مشکلی که تو این کد هست اینه که درسته redirect میکنه ولی جلوی اجرا شدن کد رو نمیگیره بعد redirect و باعث میشه مابقی کد هم اجرا بشن بعد redirect. ولی چه تهدیدی داره؟
1⃣ افشا شدن response بعد از redirect :
اگه با دستور زیر به اون مسیر curl بزنیم میتونیم کل ریسپانس رو ببینیم:
curl https://target.com/admin_panel.php
نکته : ما فقط میتونیم response رو ببینیم نه سورس کد اپلیکیشن. ممکنه برنامه نویس از توابعی استفاده کرده باشه که اطلاعات مهمی رو روی صفحه چاپ کنه مثل echo. برای درک بهتر کد زیر رو در نظر بگیرید :
<?php
if($_SESSION['is_admin'] != true)
{
hedaer("Location : /home.php");
}
echo "username : adm2ish";
echo "password : pa19ehw";
?>
2⃣ تست آسیب پذیری های مختلف!
کد زیر رو در نظر بگیرین:
<?php
session_start();
if($_SESSION['is_admin'] != true)
{
header("Location: /home.php");
}
if (isset($_GET['cmd']) && !empty($_GET['cmd'])) {
$admin_input = $_GET['cmd'];
echo system("ping $admin_input");
} else {
echo "No command provided.";
}
?>
آسیب پذیری ای که این کد داره Command Injectionهست. ولی نکته ای که مهمه اینه که این صفحه چون redirect میکنه خیلیا اینجا parameter fuzz انجام نمیدن و آسیب پذیری های این صفحه فقط با دسترسی ادمین قابل دیدن و تست کردنه، ولی بخاطر اشتباه برنامه نویس مهاجم میتونه parameter fuzz انجام بده و آسیب پذیری های مختلفی رو تست کنه که بسته به logic برنامه ممکنه آسیب پذیری های مختلفی رو داشته باشه. اگه باگ هانترین حتما به این نکته توجه داشته باشین موقع مواجه شدن با redirect ها.
نمونه پیلود با curl برای تست آسیب پذیری :
curl "https://target.com/admin_panel.php?cmd=1.1.1.1|whoami"
curl "https://target.com/admin_panel.php?cmd=1.1.1.1||whoami||"
curl "https://target.com/admin_panel.php?cmd=1.1.1.1;whoami"
نکته مهم : کد های نوشته شده با php رو اگه تو سیستمتون اجرا کنین به درستی کار نمیکنن چون باید خودتون session کاربر رو ست کنین.
⁉️روش جلوگیری چیه؟
بعد redirect باید جلوی اجرا شدن ادامه کد رو بگیریم که میتونیم با توابع زیر انجام بدیم:
<?php
exit()
die()
?>
اسم آسیب پذیری :
Execution After Redirect = EAR
#EAR
#parameter_fuzz
Forwarded from 🎄 یک برنامه نویس تنبل (Raymond Dev)
Forwarded from Go Casts 🚀
سلام، پیشنهاد می کنم حتما پادکست «تفکر شفاف» بی پلاس رو گوش بدید. هم به مهارت های نرم شما کمک میکنه که ارتباط موثرتری با همکاراتون داشته باشید، هم بهتون کمک میکنه تحلیلگر و معمار و مهندس بهتری باشید، چون مهندسی همه ش فکر کردن و تصمیم گرفتنه، پس بهتر بستر مناسبی برای تفکر خودتون آماده کنید.
https://bpluspodcast.com/podcast/seventh-season/%D8%AA%D9%81%DA%A9%D8%B1-%D8%B4%D9%81%D8%A7%D9%81/
@gocasts
https://bpluspodcast.com/podcast/seventh-season/%D8%AA%D9%81%DA%A9%D8%B1-%D8%B4%D9%81%D8%A7%D9%81/
@gocasts
Forwarded from ⚝
Forwarded from ASafaeirad
Forwarded from ASafaeirad
Forwarded from Code Module | کد ماژول (Mahan-Heydari)
کتابخانه Lit چیه و چه کاربردی داره؟ 😎
🔵 Lit یک کتابخانه مدرن برای ساخت وبکامپوننته که توسط گوگل توسعه داده شده. این کتابخانه با هدف سادهسازی فرآیند ساخت رابطهای کاربری تعاملی و بهینه، طراحی شده.
👍 Lit به شما این امکان رو میده تا کامپوننتهای reusable و scalable ایجاد کنید که میتونن در پروژههای مختلف وب به کار گرفته بشن.
Lit از ویژگیهای وبکامپوننتها مثل Shadow DOM و Custom Elements بهره گیری میکنه و به دولوپرا این امکان رو میده که با استفاده از تگهای HTML، کامپوننتهای خودشونو بسازن. این کتابخانه بهخصوص برای پروژههایی که نیاز به تعاملات پیچیده و داینامیک دارن، خیای مناسبه.
ویژگیهای کتابخانه Lit⬇️
1️⃣ سادگی و کارایی: Lit طوری طراحی شده که یادگیری و استفاده ازش آسون باشه. با استفاده از Syntax ساده و مختصر، دولوپرا میتونن به سرعت کامپوننتهای خودشونو بسازن.
2️⃣ پرفورمنس بالا: Lit با استفاده از تکنیکهای بهینهسازی، مثل تغییرات هوشمند DOM، پرفورمنس بالایی رو ارائه میده. این ویژگی باعث میشه که بارگذاری و تعاملات در صفحات وب سریعتر و راحت تر باشه.
3️⃣ قابلیت استفاده مجدد: کامپوننتهای ساختهشده با Lit به راحتی قابل استفاده مجدد داخل پروژههای مختلف هستن.
4️⃣ قابلیت ادغام آسان: Lit به راحتی با باقی فریمورکها و کتابخانهها ادغام میشه، بنابراین میتونید ازش در پروژههای موجود هم استفاده کنید.
5️⃣ پشتیبانی از TypeScript: Lit از TypeScript پشتیبانی میکنه که به دولوپرا این امکان رو میده که کدهاشونو با data type مشخص کنن و از مزایای type safety بهرهمند بشن.
کتابخانه Lit یک ابزار قدرتمند و کارآمد برای ساخت وبکامپوننتهاست که با ویژگیهای منحصر به فردش، میتونه به دولوپرا کمک کنه تا رابطهای کاربری پیچیده و تعاملی بسازن.اگر به دنبال راهی برای بهبود فرآیند توسعه وب خود هستید، Lit قطعاً یکی از گزینههای قابل توجه برای بررسیه.
برای یادگیری و مطالعه بیشتر این کتابخانه میتونید به داکیومنتش مراجعه کنید.
Document🌕
#lit #library
@CodeModule
Lit از ویژگیهای وبکامپوننتها مثل Shadow DOM و Custom Elements بهره گیری میکنه و به دولوپرا این امکان رو میده که با استفاده از تگهای HTML، کامپوننتهای خودشونو بسازن. این کتابخانه بهخصوص برای پروژههایی که نیاز به تعاملات پیچیده و داینامیک دارن، خیای مناسبه.
ویژگیهای کتابخانه Lit
کتابخانه Lit یک ابزار قدرتمند و کارآمد برای ساخت وبکامپوننتهاست که با ویژگیهای منحصر به فردش، میتونه به دولوپرا کمک کنه تا رابطهای کاربری پیچیده و تعاملی بسازن.اگر به دنبال راهی برای بهبود فرآیند توسعه وب خود هستید، Lit قطعاً یکی از گزینههای قابل توجه برای بررسیه.
برای یادگیری و مطالعه بیشتر این کتابخانه میتونید به داکیومنتش مراجعه کنید.
Document
#lit #library
@CodeModule
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from کانال اطلاعرسانی توزیع پارچ
نگارش جدید پارچ منتشر شد.
مشکل کالامارس در این نگارش رفع شده.
دریافت نگارش پلاسما
دریافت نگارش گنوم (با گنوم ۴۷)
@ParchLinux
مشکل کالامارس در این نگارش رفع شده.
دریافت نگارش پلاسما
دریافت نگارش گنوم (با گنوم ۴۷)
@ParchLinux
Forwarded from LearnPOV | لرن پی او وی
میدونستید با استفاده از متد vibrate داخل میتونید ویبره گوشی کاربر رو مدیریت کنید ؟
برای استفاده ازشم کافیه از گلوبال آبجکت navigator متد vibrate رو کال بکنید و به عنوان ورودی بهش مدت زمان ویبره رو به میلیثانیه بهش بدید
نمونه کد 🚀
برای استفاده ازشم کافیه از گلوبال آبجکت navigator متد vibrate رو کال بکنید و به عنوان ورودی بهش مدت زمان ویبره رو به میلیثانیه بهش بدید
نمونه کد 🚀
navigator.vibrate(200);
Forwarded from 🎄 یک برنامه نویس تنبل ( MΞ)
🔸ژاکت به عنوان مرجع بازار وردپرس ایران پی دی افی با عنوان اولین گزارش جامع وردپرس در ایران منتشر کرده
@TheRaymondDev
@TheRaymondDev