سلام

سایت aixploria یک لیست عالی از ابزار های هوش مصنوعی (AI) هست که به شما کمک می کنند ، ابزار مورد نیاز خودتان را پیدا و استفاده کنید

https://www.aixploria.com/en/

پس برید و از استفاده از این ابزار لذت ببرید

موفق باشید 🌹

@srfirouzi_channel

📕 کتاب REST API Design Rulebook

📌 فصل دوم: Identifier Design with URIs

📍پارت: دوم

#کتاب

‏💎 URI Authority Design 💎
این بخش به نام‌گذاری‌هایی که باید برای قسمت "authority" (یا همان بخش اصلی آدرس) یک REST API استفاده شود، می‌پردازد.

⭕️ برای API هاتون باید از نام‌های زیردامنه‌ای منظم و یکسان استفاده کنید.
دامنه اصلی و اولین زیردامنه (مثلاً soccer.restapi.org) باید مشخص‌کننده مالک سرویس باشه. کل نام دامنه یک API باید یک زیردامنه به نام api اضافه کنه. برای مثال:

http://api.soccer.restapi.org

⭕️ برای پرتال توسعه‌ دهندگان API هاتون باید از نام‌های زیردامنه‌ای منظم و یکسان استفاده کنید. خیلی از REST API ها یک وب‌سایت دارند که به عنوان پرتال توسعه‌دهندگان شناخته می‌شه و به کمک مستندات، انجمن‌ها و ارائه کلیدهای دسترسی امن به API، کاربران جدید رو راهنمایی می‌کنه. اگر API شما یک پرتال توسعه‌دهنده داره، طبق عرف باید زیردامنه‌ای به نام developer داشته باشه. برای مثال:

http://developer.soccer.restapi.org

‏💎 Resource Modeling 💎

مسیر URI مدل منابع یک REST API رو نشون می‌ده، به این صورت که هر بخش از مسیر که با اسلش جدا شده، به یک منبع منحصر به فرد در سلسله مراتب مدل اشاره می‌کنه. برای مثال، این طراحی URI:

http://api.soccer.restapi.org/leagues/seattle/teams/trebuchet

نشون می‌ده که هر کدوم از این URI‌ها هم باید به یک منبع آدرس‌پذیر اشاره کنند:

http://api.soccer.restapi.org/leagues/seattle/teams
http://api.soccer.restapi.org/leagues/seattle
http://api.soccer.restapi.org/leagues
http://api.soccer.restapi.org

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

قبل از اینکه مستقیم وارد طراحی مسیرهای URI بشید، شاید بهتر باشه اول به مدل منابع REST API فکر کنید.



‏💎 Resource Archetypes 💎

هنگام مدل‌سازی منابع یک API، می‌تونیم با چند الگوی پایه‌ای منابع شروع کنیم. مثل الگوهای طراحی، این الگوها به ما کمک می‌کنن که ساختارها و رفتارهای رایجی که در طراحی REST API‌ها وجود دارن رو به صورت منسجم بیان کنیم. یک REST API از چهار الگوی منبع مجزا تشکیل شده: سند (document)، مجموعه (collection)، فروشگاه (store)، و کنترلر (controller).

برای اینکه یک مدل منابع شفاف و ساده به مشتریان API منتقل بشه، یک REST API باید هر منبع رو فقط با یکی از این الگوها تطبیق بده. برای حفظ یکنواختی، وسوسه طراحی منابعی که ترکیبی از چند الگو هستن رو کنار بذارید. به جای این کار، بهتره منابع جداگانه‌ای طراحی کنید که به صورت سلسله‌مراتبی و/یا از طریق لینک‌ها به هم مرتبط هستن، همونطور که در فصل ۵ توضیح داده شده.

هر کدوم از این الگوهای منبع در زیرمجموعه‌های بعدی به تفصیل توضیح داده شده.

@ninja_learn_ir

📕 کتاب REST API Design Rulebook

📌 فصل دوم: Identifier Design with URIs

📍پارت: اول

#کتاب

‏💎 URIs 💎

توی وب API‌ های REST از شناسه‌های منبع یکنواخت (URIs) برای آدرس‌دهی منابع استفاده می‌کنند.
امروزه، طراحی‌های URI می‌تونن از شاهکارهایی باشن که مدل منبع API رو به وضوح نشون می‌دن،
مثل:

http://api.example.restapi.org/france/paris/louvre/leonardo-da-vinci/mona-lisa

تا اون‌هایی که خیلی سخت‌تر برای مردم قابل فهم هستن، مثل:

http://api.example.restapi.org/68dd0-a9d3-11e0-9f1c-0800200c9a66

تیم برنرز-لی یه نکته‌ای درباره شفافیت URIs توی لیست "اصول معماری وب"ش ذکر کرده:

تنها چیزی که می‌تونید از یه شناسه استفاده کنید اینه که به یه شیء ارجاع بدید. وقتی که نمی‌خواید ارجاع بدید، نباید به محتوای رشته URI نگاه کنید تا اطلاعات دیگه‌ای به دست بیارید.

همونطور که توی فصل ۵ بحث شد، مشتری‌ها باید از الگوی لینک‌دهی وب پیروی کنن و URIs رو به عنوان شناسه‌های غیرشفاف در نظر بگیرن. با این حال، طراحان API‌های REST باید URIsی طراحی کنن که مدل منبع API رو به وضوح به توسعه‌دهندگان احتمالی نشون بده.

این فصل یه سری قوانین طراحی برای URIs در API‌های REST رو معرفی می‌کنه.


‏💎 URI Format 💎
قوانینی که در این بخش ارائه شده‌اند مربوط به فرمت یک URI هستند. استاندارد RFC 3986* سینتکس کلی URI رو به این شکل تعریف می‌کنه:

URI = scheme "://" authority "/" path [ "?" query ] [ "#" fragment ]

‏scheme: پروتکل یا روشی که برای دسترسی به منبع استفاده می‌شه، مثل http یا https.
‏authority: شامل اطلاعاتی مثل دامنه (domain) یا آدرس IP، و پورت سرور.
‌‏path: مسیر یا آدرسی که منبع خاصی رو در سرور مشخص می‌کنه.
‏query: پارامترهای اضافی که برای جستجو یا فیلتر کردن داده‌ها به URI اضافه می‌شن.
‏fragment: قسمتی از URI که به بخش خاصی از منبع اشاره می‌کنه، مثل یک بخش خاص از یک صفحه وب.

این قالب کلی به ما کمک می‌کنه تا ساختار URIها رو بهتر درک کنیم و بر اساس اون‌ها، URIهایی طراحی کنیم که هم برای انسان‌ها قابل فهم باشن و هم با استانداردهای وب سازگار باشن.


⭕️ از جداکننده‌ی اسلش (/) برای نشان دادن رابطه‌ی سلسله‌مراتبی استفاده کنید.
کاراکتر اسلش (/) در بخش مسیر (path) یک URI برای نشان دادن رابطه‌ی سلسله‌مراتبی بین منابع استفاده می‌شه. به عنوان مثال:
فرض کنید یک سایت دارید که شامل کشورها و شهرهاست. در این حالت، URI شما می‌تونه به این شکل باشه:

http://api.example.com/countries/iran/tehran

در این مثال، "iran" زیرمجموعه‌ای از "countries" و "tehran" زیرمجموعه‌ای از "iran" هست، که با استفاده از اسلش (/) این ساختار سلسله‌مراتبی نشون داده شده.

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


⭕️ نباید از اسلش (/) درآخر URI ها استفاده کنید

وقتی اسلش (/) به عنوان آخرین کاراکتر در مسیر (path) یک URI قرار می‌گیره، هیچ ارزش معنایی اضافه‌ای نداره و ممکنه باعث سردرگمی بشه. بنابراین، REST APIها نباید انتظار داشته باشند که URIها با یک اسلش انتهایی تموم بشند و نباید این نوع لینک‌ها رو به کاربران ارائه بدهند.

بسیاری از اجزای وب و فریمورک‌ها، این دو URI رو به طور یکسان در نظر می‌گیرند:

http://api.canvas.restapi.org/shapes/

http://api.canvas.restapi.org/shapes

اما واقعیت اینه که هر کاراکتر در یک URI به شناسایی منحصر به فرد اون منبع کمک می‌کنه. دو URI متفاوت به دو منبع متفاوت اشاره می‌کنند. بنابراین، یک REST API باید URIهای تمیز و دقیق تولید کنه و نباید تلاش‌های کاربران برای شناسایی منابع به شکل نادرست رو بپذیره.

البته، APIهای منعطف‌تر ممکنه کاربران رو به URIهایی بدون اسلش انتهایی هدایت کنند (همون‌طور که در قانون مربوط به استفاده از کد وضعیت 301 "Moved Permanently" برای جابجایی منابع توضیح داده شده).


⭕️ برای بهبود خوانایی URIها از خط تیره (-) استفاده کنید

برای اینکه URIهاتون رو برای افراد قابل فهم و قابل اسکن کنید، از کاراکتر خط تیره (-) استفاده کنید تا خوانایی نام‌ها در بخش‌های طولانی مسیر (path) بهتر بشه. هر جایی که در زبان انگلیسی از فاصله یا خط تیره استفاده می‌کنید، در URI هم باید از خط تیره استفاده کنید. به عنوان مثال:

http://api.example.restapi.org/blogs/mark-masse/entries/this-is-my-first-post

این کار باعث میشه که URIها هم از نظر ظاهری بهتر و هم از نظر فهم و کاربرد راحت‌تر بشند.

#کتاب

📕 کتاب REST API Design Rulebook

📌 فصل اول: معرفی (Introduction)

📍پارت: چهارم (پارت آخر فصل اول)

#کتاب

💎 WRML 💎

من (نویسنده کتاب) یه چارچوب مفهومی به نام Web Resource Modeling Language (WRML) اختراع کردم که به طراحی و پیاده‌سازی REST API ها کمک می‌کنه. WRML، که به صورت "ورمل" تلفظ می‌شه، اول به عنوان یه تکنیک برای رسم مدل منابع به وجود اومد که از یه سری اشکال ساده برای نمایش هر کدوم از الگوهای منابع استفاده می‌کنه.

دامنه‌ی WRML با ایجاد نوع رسانه‌ای به نام application/wrml که قابلیت اضافه کردن فرمت و اجزای اسکیمای جدید رو داره، گسترده‌تر شد. در خیلی از قواعد بعدی کتاب، از ایده‌های WRML استفاده می‌کنم تا شکاف‌های موجود در بهترین روش‌های فعلی رو با توصیه‌های منطقی برای موقعیت‌های رایج پر کنم.

در فصل‌های ۵ و ۶ متوجه می‌شی که خیلی از قوانین با مثال‌هایی که از JSON استفاده می‌کنن، توضیح داده شدن. JSON یه فرمت مهمه که مزایای زیادی داره، مثل پشتیبانی بومی از جاوااسکریپت، پذیرش تقریبا جهانی، و سینتکس آشنا. اما JSON به تنهایی ساختارهای یکسانی برای بعضی از مهم‌ترین مفاهیم REST API مثل لینک‌ها، روابط لینک‌ها، و اسکیم‌ها ارائه نمی‌ده. قوانین توی فصل‌های "نمایش هایپرمیدیا" و "نمایش اسکیم" از WRML استفاده می‌کنن تا فرم‌های نمایشی مبتنی بر JSON رو برای این ساختارهای اصلی نشون بدن.

در نهایت، فصل ۷ تأکید می‌کنه که یکنواختی در طراحی API فقط یه موضوع تئوری نیست؛ بلکه می‌تونه زندگی برنامه‌نویسا رو بهتر کنه و به ما ابزاری غنی بده تا با استفاده از اون‌ها REST API ‌های بهتری طراحی و توسعه بدیم.


✅ خلاصه
این فصل خلاصه‌ای از اختراع و تثبیت وب رو ارائه داد. همچنین به معرفی رویکرد قوانین‌محور کتاب و چارچوب مفهومی WRML پرداخت، که ایده‌های اون به طراحی یکپارچه REST API کمک می‌کنن. فصل‌های بعدی بر این پایه استوار می‌شن تا به ما کمک کنن که از REST در طراحی API استفاده کنیم.

جدول ۱-۱ هم خلاصه‌ای از اصطلاحات جدیدی که توی این فصل معرفی شدن رو ارائه می‌ده.

@ninja_learn_ir

#کتاب

📕 کتاب REST API Design Rulebook

📌 فصل اول: معرفی (Introduction)

📍پارت: سوم

#کتاب

💎 REST 💎
در سال ۲۰۰۰، بعد از اینکه مشکل مقیاس‌پذیری وب حل شد، فیلدینگ تو پایان‌نامه دکترای خودش سبک معماری وب رو اسم‌گذاری کرد و اسمش رو "انتقال حالت نمایشی" یا همون REST رو برای این سبک معماری انتخاب کرد. این سبک شامل محدودیت‌هایی هست که قبلاً بهشون اشاره کردیم.

💎 REST API ها 💎

وب سرویس‌ها (Web Services) سرورهای مخصوصی هستن که نیازهای یه سایت یا هر اپلیکیشن دیگه‌ای رو برطرف می‌کنن.

برنامه‌های کلاینت (یا همون نرم‌افزارهایی که با سرور ارتباط می‌گیرن) از طریق API با این وب سرویس‌ها ارتباط برقرار می‌کنن.

به زبان ساده، API ها یه سری داده و عملکرد رو در اختیار برنامه‌های دیگه قرار می‌دن تا بتونن با هم تعامل کنن و اطلاعات رد و بدل کنن.

یه وب API مثل ویترین یه وب سرویسه که مستقیماً درخواست‌های کلاینت رو می‌شنوه و بهشون جواب می‌ده.

سبک معماری REST معمولاً برای طراحی API های وب سرویس‌های مدرن استفاده می‌شه. اگه یه وب API با سبک معماری REST طراحی شده باشه، بهش می‌گیم REST API.


⭕️ نکات:

مقیاس‌پذیری: یعنی یه سیستم بتونه بدون کاهش کیفیت، با افزایش ترافیک (مثلا تعداد کاربران) کنار بیاد و بتونه هندلشون کنه.

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

وب سرویس: یه سرویس تحت وب که از طریق اینترنت قابل دسترسیه و خدمات خاصی رو ارائه می‌ده.

API: یه واسطه که به برنامه‌ها اجازه می‌ده با هم ارتباط برقرار کنن.


وقتی یه وب سرویس از REST API استفاده کنه، بهش می‌گیم که اون سرویس "RESTful" هست. یه REST API از یه سری منابع به هم پیوسته تشکیل شده که بهشون مدل منابع (Resource Model) گفته می‌شه. REST API هایی که خوب طراحی شده باشن، می‌تونن برنامه‌نویس‌های کلاینت رو جذب کنن تا از اون وب سرویس استفاده کنن. امروزه که سرویس‌های وب رقیب دارن با هم برای جلب توجه رقابت می‌کنن، داشتن یه REST API با طراحی تمیز و کاربرپسند یه ویژگی ضروریه.

طراحی REST API برای خیلی از ماها بیشتر شبیه یه هنره تا یه علم. یه سری از بهترین روش‌ها برای طراحی REST API توی استاندارد HTTP وجود داره، ولی یه سری روش‌های دیگه هم طی سال‌های اخیر به‌صورت نیمه‌استاندارد شکل گرفته.

با این حال، هنوز هم باید دنبال جواب برای یه سری سوالات مهم بگردیم، مثلا:

- کی باید اسم route هامون رو با اسم‌های جمع بنویسیم؟
- از کدوم متد ریکوست (مثل POST یا PUT) باید برای به‌روزرسانی وضعیت منابع استفاده کنیم؟
- چطور باید عملیات‌هایی که مربوط به CRUD نیستن (CRUD: ایجاد، خواندن، به‌روزرسانی، حذف) رو به route ها مپ کنیم؟
- کدوم کد استاتوس HTTP برای یه سناریوی خاص مناسبه؟
- چطور می‌تونم نسخه‌های مختلف نمایه‌های وضعیت یه منبع رو مدیریت کنم؟
- چطور باید لینک‌ها رو توی JSON ساختاردهی کنم؟

⭕️ نکات:
- URI آدرس مشخصی که برای دسترسی به یه منبع توی وب استفاده می‌شه.
- CRUD مخفف چهار عمل اصلی روی داده‌ها؛ ایجاد (Create)، خواندن (Read)، به‌روزرسانی (Update)، و حذف (Delete).
- HTTP Status Code کدهایی که وضعیت درخواست‌های HTTP رو نشون می‌دن، مثل 200 برای موفقیت‌آمیز بودن یا 404 برای پیدا نشدن.


این کتاب یه سری قوانین طراحی REST API رو معرفی می‌کنه که هدفش اینه تا جواب‌های واضح و مختصری به سوالات مهمی که مطرح کردیم، بده.
این قوانین می‌خوان بهت کمک کنن تا REST API هایی با یکپارچگی و نظم طراحی کنی که بتونن به‌خوبی توسط کلاینت‌هایی که ازشون استفاده می‌کنن، بهره‌برداری بشن. می‌تونی این قوانین رو کامل دنبال کنی یا هر کدوم که دوست داشتی انتخاب کنی. شاید با بعضی از این قوانین مخالفت کنی، ولی من معتقدم هر کدومشون ارزش بررسی دقیق رو دارن.

خیلی از قوانین طراحی این کتاب از بهترین روش‌هایی گرفته شدن که به‌نوعی استانداردهای نانوشته‌ای شده‌ان. اگه تجربه‌ای توی طراحی REST API ها داری، احتمالاً با قوانینی که مربوط به طراحی URI در فصل ۲ و استفاده از HTTP در فصل ۳ هستن، آشنا خواهی بود. ولی در مقابل، بیشتر قوانین فصل ۴ و فصل ۵ (مخصوصاً اونایی که به نوع داده‌ها و فرم‌های نمایشی مربوط می‌شن) راه‌حل‌هایی هستن که خودم برای مسائلی که توافقی روشون نیست، ارائه دادم.

@ninja_learn_ir

#کتاب

📕 کتاب REST API Design Rulebook

📌 فصل اول: معرفی (Introduction)

📍پارت: دوم

#کتاب

💎 معماری وب 💎

در اواخر سال ۱۹۹۳، "روی فیلدینگ"، یکی از بنیان‌گذاران پروژه سرور HTTP آپاچی، نگران مشکل مقیاس‌پذیری وب شد.
بعد از تحلیل، فیلدینگ متوجه شد که مقیاس‌پذیری وب تحت تأثیر یه سری محدودیت‌های کلیدی قرار داره. اون و دیگران تصمیم گرفتن که با یه رویکرد عملیاتی، وب رو بهبود بدن: باید همه این محدودیت‌ها رو به‌صورت یکسان برآورده کنن تا وب بتونه به گسترش خودش ادامه بده.
فیلدینگ این محدودیت‌ها رو به شش دسته تقسیم کرد و به مجموعه این دسته‌ها "سبک معماری وب" گفت:

۱. کلاینت-سرور (Client-server)
۲. رابط یکپارچه (Uniform interface)
۳. سیستم لایه‌ای (Layered system)
۴. کش (Cache)
۵. بدون حالت (Stateless)
۶. کد به‌صورت درخواستی (Code-on-demand)

1️⃣ کلاینت-سرور (Client-server)
موضوع اصلی محدودیت‌های کلاینت-سرور در وب، جداسازی وظایف است. وب یک سیستم مبتنی بر کلاینت-سرور است که در آن کلاینت‌ها و سرورها نقش‌های مجزا و مشخصی دارند. این بخش‌ها می‌توانند به‌صورت مستقل پیاده‌سازی و مستقر شوند، با استفاده از هر زبان یا فناوری، به شرطی که با رابط یکنواخت وب سازگار باشند.

2️⃣ رابط یکپارچه (Uniform interface)
تعاملات بین اجزای وب، یعنی کلاینت‌ها، سرورها و واسطه‌های مبتنی بر شبکه، به یکنواختی رابط‌هایشان بستگی دارد. اگر هر یک از این اجزا از استانداردهای تعیین‌شده خارج شوند، سیستم ارتباطی وب دچار اختلال می‌شود.
اجزای وب در چارچوب چهار محدودیت رابط یکنواخت که فیلدینگ شناسایی کرده است، به‌طور سازگار با هم کار می‌کنند:

1- شناسایی منابع
2- دستکاری منابع از طریق نمایه‌ها
3- پیام‌های خودتوصیفی
4- هایپرمدیا به عنوان موتور حالت برنامه (HATEOAS)

1- شناسایی منابع
هر مفهوم مجزای مبتنی بر وب به عنوان یک منبع شناخته می‌شود و می‌تواند با یک شناسه یکتا، مثل URI، مورد خطاب قرار گیرد. برای مثال، یک URI خاص مثل http://www.google.com منحصراً به مفهوم ریشه‌ی یک وبسایت خاص اشاره دارد.

2- دستکاری منابع از طریق نمایه‌ها
کلاینت‌ها نمایه‌های منابع را دستکاری می‌کنند. یک منبع مشخص می‌تواند به شکل‌های مختلف برای کلاینت‌های مختلف نمایه شود. مثلاً، یک سند ممکن است به‌صورت HTML به یک مرورگر وب نمایش داده شود و به‌صورت JSON به یک برنامه خودکار. ایده کلیدی این است که نمایه‌ها راهی برای تعامل با منبع هستند، اما خود منبع نیستند. این تمایز مفهومی اجازه می‌دهد که منبع به روش‌ها و فرمت‌های مختلف نمایه شود بدون اینکه شناسه‌اش تغییر کند.

3- پیام‌های خودتوصیفی (Self-denoscriptive)
وضعیت مورد نظر یک منبع می‌تواند در پیام درخواست کلاینت نمایه شود. وضعیت کنونی منبع ممکن است در پیام پاسخ سرور که بازمی‌گردد، نمایش داده شود. به‌عنوان مثال، یک ویرایشگر صفحه ویکی ممکن است از پیام درخواست برای انتقال یک نمایه که پیشنهاد یک بروزرسانی صفحه (وضعیت جدید) برای یک صفحه وب مدیریت‌شده توسط سرور است، استفاده کند. سرور تصمیم می‌گیرد که درخواست کلاینت را بپذیرد یا رد کند.

4- هایپرمدیا به عنوان موتور حالت برنامه (HATEOAS)
نمایش وضعیت یک منبع شامل لینک‌هایی به منابع مرتبط هست. لینک‌ها مثل نخ‌هایی هستند که وب رو به هم متصل می‌کنن و به کاربرا این امکان رو می‌دن که به صورت معنادار و هدفمند بین اطلاعات و برنامه‌ها حرکت کنن. وجود یا نبودن یه لینک روی یک صفحه، بخش مهمی از وضعیت فعلی اون منبعه.

3️⃣ سیستم لایه‌ای (Layered system)
محدودیت‌های سیستم لایه‌ای این امکان رو می‌ده که واسطه‌های مبتنی بر شبکه مثل پروکسی‌ها و درگاه‌ها، به‌صورت شفاف بین کلاینت و سرور مستقر بشن و از رابط یکنواخت وب استفاده کنن. به‌طور کلی، یه واسطه مبتنی بر شبکه برای یه هدف مشخص ارتباط کلاینت و سرور رو رهگیری می‌کنه. این واسطه‌ها معمولاً برای اجرای امنیت، کش کردن پاسخ‌ها و متعادل کردن بار ترافیکی استفاده می‌شن.

4️⃣ کش (Cache)
کش کردن یکی از مهم‌ترین محدودیت‌های معماری وب هست. محدودیت‌های مربوط به کش به سرور وب می‌گن که باید قابلیت کش شدن داده‌های هر پاسخ رو مشخص کنه. کش کردن داده‌های پاسخ می‌تونه به کاهش تأخیر احساس‌شده توسط کاربر، افزایش دسترسی‌پذیری و قابلیت اطمینان یک برنامه، و کنترل بار سرور وب کمک کنه. به طور خلاصه، کش کردن هزینه کلی وب رو کاهش می‌ده.
کش می‌تونه در هر جایی از مسیر شبکه بین کلاینت و سرور وجود داشته باشه. این کش‌ها ممکنه در شبکه سرور وب یک سازمان، داخل شبکه‌های تحویل محتوای تخصصی (CDNها) یا حتی داخل خود کلاینت باشن.

ضمن خوش آمد گویی به دوستانی که تازه به جمعمون اضافه شدن 🌹، باید بگم که ما هر روز بخشی از خلاصه کتاب REST API Design Rulebook رو داخل کانال منتشر میکنیم و میتونید مطالعه کنید.

فایل PDF هم قبلا آپلود شده، فقط کافیه سرچ بزنید 🔎

از هشتگ #کتاب هم میتونید استفاده کنید برای دسترسی سریعتر #️⃣

استفاده کنید 😄❤️

Consumer data platform

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

همه اینا با استفاده از Customer data platform(CDP) انجام میشه.

تو این وب سایت میتونید دربارش اطلاعات بیشتری بدست بیارید:
https://revium.com.au/blog/what-is-segment-cdp

#CDP

@Syntax_fa

توی کانال های نخونده تلگرام یوهو اسم بیت واردن و دیدم چشام تیز شد. تو دلم گفتم الان نگه هک شده یا ...
اما نه بیت واردن کارش درست تر از این حرفاس!
اگر دنبال پسورد منیجر رایگان و خوب و امن میگردید بیت واردن جزو خوباس و سینکش هم رایگان هست. حتی هزینه دلاری اشتراکش هم اونقدری گرون نیست از قدیم یادمه.

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

دوستان برای دسترسی دلفین به محتوای ریشه نیازی نیست برید فایل منیجر ثونار یا ناتیلوس گنوم رو نصب کنید!!!!!!!!


واقعاً از برخی از دوستان در عجبم در این زمینه.


برای داشتن دسترسی ریشه داخل برنامه‌های کی‌دی‌ای از جمله دلفین باید بسته kio-admin رو نصب کنید.

بعدش توی میله مکان (location bar) بنویسید:
admin:///



@SohrabContents

ماژول perf_hooks چیکار میکنه؟ ⚡️

ماژول perf_hooks در Node.js یک ابزار قدرتمند برای نظارت بر عملکرد و بهینه سازی هست. این یک رابط برای اندازه‌گیری عملکرد عملیات مختلف در یک برنامه ارائه میکنه و دولوپر ها رو قادر میسازه تا Bottleneck رو شناسایی، کد رو بهینه و معیارهای کلیدی مثل تاخیرهای حلقه رویداد، زمان‌های اجرای عملکرد و موارد دیگه رو نظارت کنن.

ماژول «perf_hooks» در درجه اول بر روی اندازه‌گیری‌های عملکرد با وضوح بالا تمرکز داره. مثلا با استفاده از روش «performance.now()»، دولوپر ها میتونن فواصل زمانی دقیق تا میکروثانیه رو اندازه‌گیری کنن که برای ردیابی مدت زمان انجام عملیات خاص مفید هست.

- مثال:

     const { performance } = require('perf_hooks');
     const start = performance.now();
     // Execute some code here
     const end = performance.now();
     console.log(`Execution took ${end - start} milliseconds.`);
     

به صورت کلی ماژول perf_hooks ابزارهای ضروری رو برای درک و بهینه سازی عملکرد برنامه به دولوپر های Node.js، ارائه میده. با ارائه معیارهای دقیق در زمان‌بندی، تاخیرهای حلقه رویداد و استفاده از حافظه، به دولوپر ها کمک میکنه تا مشکلات عملکرد رو تشخیص داده و کارایی برنامه رو افزایش بدن. برای اطلاعات بیشتر به داکیومنت این ماژول مراجعه کنید.

#nodejs
@CodeModule

اگر تا امروز موفق به نصب نسخه تست‌فلایت اپ #هیدیفای در #آیفون نشدین، از طریق لینک زیر اقدام کنین:

👉 https://testflight.apple.com/join/URrT6ZWm

🔍 ircf.space/software.php
@ircfspace

اگر تا امروز موفق به نصب نسخه تست‌فلایت اپ #هیدیفای در #آیفون نشدین، از طریق لینک زیر اقدام کنین:

👉 testflight.apple.com/join/URrT6ZWm

🔍 ircf.space/software.php
@ircfspace

این‌ابزار کاربردی امکان اصلاح کانفیگ‌های Vless/Vmess پشت CDN رو با استفاده از رنج آی‌پی‌های کلودفلر یا آی‌پی‌های موردنظر فراهم میکنه.

👉 seramo.github.io/v2ray-config-modifier
💡 github.com/seramo/v2ray-config-modifier
© seramo_ir

🔍 ircf.space
@ircfspace

css-tricks.com/bem-101

مقاله‌ای راجع به BEM در CSS:

#learn #article #css
@amiria703_channel

کامند های artisan توی لاراول 11

#php #laravel
@CleverDevs - @CleverDevsGp