Forwarded from کداکسپلور | CodeExplore (Koorosh)
کاربرد اعداد BigInt در جاوااسکریپت ✌️
میدونستین توی جاوااسکریپت این شرط برقراره؟
اما چرا؟ چون توی جاوااسکریپت، بزرگترین عدد صحیحی که میتونین با دقت کامل توی متغیرها ذخیره کنید، Number.MAX_SAFE_INTEGER هست که برابر با 9007199254740991 است. اگه عددی بزرگتر از این باشه، جاوااسکریپت دیگه نمیتونه به درستی اون رو مدیریت کنه و مقایسهاش دقیق نیست.
راه حلش چیه؟ باید اعدادتون رو BigInt تعریف کنید. چطوری؟ اینطوری:
البته میتونید اینکار رو هم بکنید:
#javanoscript #js #trick
☕️ @CodeExplore
میدونستین توی جاوااسکریپت این شرط برقراره؟
console.log(9999999999999999 === 10000000000000000);
// true
اما چرا؟ چون توی جاوااسکریپت، بزرگترین عدد صحیحی که میتونین با دقت کامل توی متغیرها ذخیره کنید، Number.MAX_SAFE_INTEGER هست که برابر با 9007199254740991 است. اگه عددی بزرگتر از این باشه، جاوااسکریپت دیگه نمیتونه به درستی اون رو مدیریت کنه و مقایسهاش دقیق نیست.
راه حلش چیه؟ باید اعدادتون رو BigInt تعریف کنید. چطوری؟ اینطوری:
let bigNumber = 1234567890123456789012345678901234567890n;
console.log(bigNumber);
//1234567890123456789012345678901234567890n
البته میتونید اینکار رو هم بکنید:
let number= 42
let bignumber = BigInt(number)
#javanoscript #js #trick
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from 🎄 یک برنامه نویس تنبل ( MΞ)
🔸باگ رفرال
امروز میخوام یه باگ از رفرال(زیرمجوعه گیری) رباتای تلگرام پابلیک کنم که تقریبا ازکار افتاده 🗿
ساختار لینک دعوت به این صورت:
که وقتی روش کلیک میکنید زیر مجموعه یوزری با ایدی
باگ دقیقا همینجا چون قابل پیشبینی هستن
پس اگه ما بیایم قبل از عضو شدن به ربات ایدی خودمونو جای لینک بالا بزاریم و عضو بشیم انگار زیر مجموعه خودمون شدیم
الان اکثر رباتایی که بالا میان اینو یه چیز رندوم میزارن که قابل پیشبینی نباشه مثل تصویر بالا
@TheRaymondDev
امروز میخوام یه باگ از رفرال(زیرمجوعه گیری) رباتای تلگرام پابلیک کنم که تقریبا ازکار افتاده 🗿
ساختار لینک دعوت به این صورت:
https://news.1rj.ru/str/bot?start=11111111
که وقتی روش کلیک میکنید زیر مجموعه یوزری با ایدی
11111111 میشیدباگ دقیقا همینجا چون قابل پیشبینی هستن
پس اگه ما بیایم قبل از عضو شدن به ربات ایدی خودمونو جای لینک بالا بزاریم و عضو بشیم انگار زیر مجموعه خودمون شدیم
الان اکثر رباتایی که بالا میان اینو یه چیز رندوم میزارن که قابل پیشبینی نباشه مثل تصویر بالا
@TheRaymondDev
Forwarded from محتوای آزاد سهراب
میخوام ویدئو ضبط کنم ولی نمیدونم درچه موضوعی 🥳
قبلاً قول یک پلیلیست هم داده بودم برای (آموزش کار با گنو/لینوکس) که خیلی کلیشهایه و از این دست محتواها زیاد پیدا میشه.
🥰 @SohrabContents
قبلاً قول یک پلیلیست هم داده بودم برای (آموزش کار با گنو/لینوکس) که خیلی کلیشهایه و از این دست محتواها زیاد پیدا میشه.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Code Module | کد ماژول (Mahan-Heydari)
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Gopher Academy
🔵 عنوان مقاله
Go Performance from Version 1.0 to 1.22
🟢 خلاصه مقاله:
مقالهای که به بررسی تحلیلی عملکرد زبان برنامهنویسی Go از نسخه ۱.۰ تا آخرین نسخه یعنی ۱.۲۲ میپردازد، ادامهای است بر تحلیلهای قبلی نویسنده از نسخههای ۱.۲ تا ۱.۱۸ که دو سال پیش منتشر شده بود. در این مقاله، تحولات و بهینهسازیهای صورت گرفته در عملکرد زبان Go طی این سالها از ابتدای تولید تا به امروز بررسی شده است. نویسنده با استفاده از دادهها و شواهد محکم، تغییرات کلیدی در معماری و عملکرد زبان را به تفصیل تشریح کرده و نشان میدهد که چگونه این تحولات به افزایش کارایی و بهرهوری در برنامهنویسی کمک کردهاند. این مقاله میتواند منبع مفیدی برای توسعهدهندگان و مهندسان نرمافزار باشد که میخواهند دیدگاه عمیقتری نسبت به تکامل زبان Go و عملکرد آن داشته باشند.
🟣لینک مقاله:
https://benhoyt.com/writings/go-version-performance-2024/
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Go Performance from Version 1.0 to 1.22
🟢 خلاصه مقاله:
مقالهای که به بررسی تحلیلی عملکرد زبان برنامهنویسی Go از نسخه ۱.۰ تا آخرین نسخه یعنی ۱.۲۲ میپردازد، ادامهای است بر تحلیلهای قبلی نویسنده از نسخههای ۱.۲ تا ۱.۱۸ که دو سال پیش منتشر شده بود. در این مقاله، تحولات و بهینهسازیهای صورت گرفته در عملکرد زبان Go طی این سالها از ابتدای تولید تا به امروز بررسی شده است. نویسنده با استفاده از دادهها و شواهد محکم، تغییرات کلیدی در معماری و عملکرد زبان را به تفصیل تشریح کرده و نشان میدهد که چگونه این تحولات به افزایش کارایی و بهرهوری در برنامهنویسی کمک کردهاند. این مقاله میتواند منبع مفیدی برای توسعهدهندگان و مهندسان نرمافزار باشد که میخواهند دیدگاه عمیقتری نسبت به تکامل زبان Go و عملکرد آن داشته باشند.
🟣لینک مقاله:
https://benhoyt.com/writings/go-version-performance-2024/
➖➖➖➖➖➖➖➖
👑 @gopher_academy
Benhoyt
Go performance from version 1.0 to 1.22
Shows how much the performance of Go has improved from version 1.0 through to 1.22 (including PGO) -- in its compiler, runtime, and libraries.
Forwarded from کداکسپلور | CodeExplore (Koorosh)
جاوااسکریپت چطوری خلق شد؟ ✌️
📌 یه نکته جالب درباره جاوااسکریپت که خیلیها نمیدونن اینه که جاوااسکریپت در اصل در ۱۰ روز توسط یک برنامهنویس به نام برندان آیک ساخته شد! اون زمان شرکت Netscape به سرعت به یه زبان اسکریپتنویسی برای وب نیاز داشت تا بتونه با رقبا رقابت کنه. این زبان اول به نام Mocha معرفی شد، بعد اسمش شد LiveScript و نهایتاً برای استفاده از شهرت جاوا، اسمش رو به جاوااسکریپت تغییر دادن، با اینکه ارتباط زیادی با جاوا نداره.
💥 در واقع، جاوااسکریپت خیلی سریع طراحی شد و انتظار نمیرفت که تبدیل به یکی از مهمترین زبانهای وب بشه!
#javanoscript #js
☕️ @CodeExplore
#javanoscript #js
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from کانال مهرداد لینوکس (Mehrdad Linux)
Forwarded from Go Casts 🚀
سراب دنیای نرم افزاری
برای خودم زیاد پیش میاد که دچار هیجان مثبت و منفی بیش از حد بشم در مورد یه چیزی حین کار.
این هیجان میتونه در مورد یه ایده جدید باشه، در مورد یادگیری یه موضوع جدید باشه، یا حتی استرس یه incident و باگ باشه.
خیلی اوقات دوست دارم تا بی نهایت وقت داشته باشم که روی یک محصول نرم افزاری کار کنم ولی از اینکه چنین وقتی ندارم ناامید میشم.
بعضی وقت ها هم که خیلی غرق کار میشم یهو از درون خالی میشم و دچار پوچی میشم، حس بیهوده بودن میکنم، اینکه اصلا چرا دارم این کار رو میکنم، آینده ش چی میشه و غیره
چنین حس هایی ممکنه کم و بیش سراغ خیلی ها اومده باشه
نسخه ای که سعی میکنم برای خودم بپیچم اینه که سعی کنم از هیچ چیزی رویا نسازم، توهم فانتزی و خیالی نداشته باشم در مورد ساخت محصول خاصی یا موقعیت خاصی
این نسخه ممکنه گاها باعث دلسردی هم بشه، اما برای من حداقل فکر میکنم منفعت هاش بیشتر از مضراتش هست، چون بهم کمک میکنه یه تعادلی بین کار و زندگی ایجاد کنم، نه کار رو اونقدر شیرین و جذاب ببینم که زمان هایی که کار نمیکنم افسوس بخورم، و نه اونقدر کار رو سخت و پر استرس ببینم که نخوام سمت ش برم، داشتن دید واقع بینانه نسبت به حال و آینده کار در حد توان(طبیعتا خیلی چیزهای آینده رو نمیشه پیش بینی کرد)، فکر میکنم باعث بشه سطح انتظارمون رو بهتر تشخیص بدیم و از کاری که میکنیم به طور میانگین بیشتر لذت ببریم و کمتر حسرت کارهای انجام نداده رو بخوریم.
دو سه روز پیش این مصاحبه از آقای اسمش رو نبر (اینقدر که تلفظش سخته!) دیدم، سازنده زبان سی پلاس پلاس، که توصیه های جالبی داشتند که کم و بیش مرتبطه به این موضوع، دوست داشتید ببینید
https://www.youtube.com/watch?v=-QxI-RP6-HM
@gocasts
برای خودم زیاد پیش میاد که دچار هیجان مثبت و منفی بیش از حد بشم در مورد یه چیزی حین کار.
این هیجان میتونه در مورد یه ایده جدید باشه، در مورد یادگیری یه موضوع جدید باشه، یا حتی استرس یه incident و باگ باشه.
خیلی اوقات دوست دارم تا بی نهایت وقت داشته باشم که روی یک محصول نرم افزاری کار کنم ولی از اینکه چنین وقتی ندارم ناامید میشم.
بعضی وقت ها هم که خیلی غرق کار میشم یهو از درون خالی میشم و دچار پوچی میشم، حس بیهوده بودن میکنم، اینکه اصلا چرا دارم این کار رو میکنم، آینده ش چی میشه و غیره
چنین حس هایی ممکنه کم و بیش سراغ خیلی ها اومده باشه
نسخه ای که سعی میکنم برای خودم بپیچم اینه که سعی کنم از هیچ چیزی رویا نسازم، توهم فانتزی و خیالی نداشته باشم در مورد ساخت محصول خاصی یا موقعیت خاصی
این نسخه ممکنه گاها باعث دلسردی هم بشه، اما برای من حداقل فکر میکنم منفعت هاش بیشتر از مضراتش هست، چون بهم کمک میکنه یه تعادلی بین کار و زندگی ایجاد کنم، نه کار رو اونقدر شیرین و جذاب ببینم که زمان هایی که کار نمیکنم افسوس بخورم، و نه اونقدر کار رو سخت و پر استرس ببینم که نخوام سمت ش برم، داشتن دید واقع بینانه نسبت به حال و آینده کار در حد توان(طبیعتا خیلی چیزهای آینده رو نمیشه پیش بینی کرد)، فکر میکنم باعث بشه سطح انتظارمون رو بهتر تشخیص بدیم و از کاری که میکنیم به طور میانگین بیشتر لذت ببریم و کمتر حسرت کارهای انجام نداده رو بخوریم.
دو سه روز پیش این مصاحبه از آقای اسمش رو نبر (اینقدر که تلفظش سخته!) دیدم، سازنده زبان سی پلاس پلاس، که توصیه های جالبی داشتند که کم و بیش مرتبطه به این موضوع، دوست داشتید ببینید
https://www.youtube.com/watch?v=-QxI-RP6-HM
@gocasts
YouTube
(Life) Advice From The Creator of C++
The creator of C++, Bjarne Stroustrup, shares some valuable life advice that, let’s face it, all developers, no matter their years of experience could use. According to Bjarne, ‘You can’t just do code’, you need to develop more skills if you want to be a…
Forwarded from کداکسپلور | CodeExplore (𝙰𝚖𝚒𝚗)
#api #github
Please open Telegram to view this post
VIEW IN TELEGRAM
GitHub
GitHub - toddmotto/public-apis: A collective list of free APIs
A collective list of free APIs. Contribute to toddmotto/public-apis development by creating an account on GitHub.
Forwarded from جادی | Jadi
این دفعه در حل سوالات مصاحبه کاری به یه سوال بامزه و راحت و سر راست برخوردیم؛ شانس داشتیم: یه رشته کاراکتری رو گرفتین (شبیه یه جمله) و باید طول آخرین کلمهای که توش هست رو برگردونین. چون ساده و سر راست است با سی می نویسیم (:
https://youtu.be/FKbN477bdxM
https://youtu.be/FKbN477bdxM
YouTube
سوالات الگوریتمی برای فان و مصاحبه: طول آخرین کلمه در یک جمله
هوم. این به نظر سر راست میاد: یک رشته (عبارت متنی) بگیرین و طول آخرین کلمهای که توش هست رو برگردونین. چون آسونه با سی می نویسیم (: البته گار درست یادم باشه.
https://leetcode.com/problems/length-of-last-word/
به حامیان کانال بپیوندین (:
https://www.yo…
https://leetcode.com/problems/length-of-last-word/
به حامیان کانال بپیوندین (:
https://www.yo…
Forwarded from Agora (Alireza Azadi)
این رشته توییت جالب از سرگذشت «یک میلیون چکباکس» رو از دست ندین:
https://x.com/Loc0m0/status/1832188628719825347
خود ماجرا رو هم میتونید از زبون خود سازنده، تو یوتیوب ببینید که بامزهس:
https://youtu.be/OI4DbECnp8A?si=T3Y0PLuPrZMFNCBh
https://x.com/Loc0m0/status/1832188628719825347
خود ماجرا رو هم میتونید از زبون خود سازنده، تو یوتیوب ببینید که بامزهس:
https://youtu.be/OI4DbECnp8A?si=T3Y0PLuPrZMFNCBh
YouTube
The Secret Inside One Million Checkboxes
My favorite story from One Million Checkboxes (https://onemillioncheckboxes.com) - a website of mine that became shockingly popular. It begins with me thinking I was hacked and ends with my crying some (very proud) tears due to some very talented teens.
…
…
Forwarded from محتوای آزاد سهراب
Forwarded from Linuxor ?
این یه SD Card ساده نیست یه کامپیوتر که یه ماژول Wi-Fi داره و یه لینوکس کوچولو برای اشتراک گذاری دیتا ها از طریق Wi-Fi.
به این صورته که مثلا به دوربین عکاسیتون وصلش میکنید و اگه با دوربین عکس یا فیلم بگیرید توی این SD Card ذخیره میشه و اگه با گوشیتون به Wi-Fi ش وصل شید داخل مروگر گوشیتون روی یه Ip خاص که بهتون میده میتونید فایل های ایجاد شده داخل SD Card رو بی سیم دانلود و مدیریت کنید.
🐧 @Linuxor ~ photo : QVHankel
به این صورته که مثلا به دوربین عکاسیتون وصلش میکنید و اگه با دوربین عکس یا فیلم بگیرید توی این SD Card ذخیره میشه و اگه با گوشیتون به Wi-Fi ش وصل شید داخل مروگر گوشیتون روی یه Ip خاص که بهتون میده میتونید فایل های ایجاد شده داخل SD Card رو بی سیم دانلود و مدیریت کنید.
🐧 @Linuxor ~ photo : QVHankel
Forwarded from کداکسپلور | CodeExplore (R.Po)
تو ریپازیتوری گیتهاب زیر میتونین اصطلاحات Functional Programming رو یاد بگیرید ( این سایت رو واسه دوستانی معرفی کردم که اصطلاحات برنامه نویسی رو نمی دونن )
🌐 http://git.io/fp-jargons
#پست_پیشنهادی
#programming #expression
☕️ @CodeExplore
#پست_پیشنهادی
#programming #expression
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from چنل شخصی سید رحیم فیروزی
سلام
سایت aixploria یک لیست عالی از ابزار های هوش مصنوعی (AI) هست که به شما کمک می کنند ، ابزار مورد نیاز خودتان را پیدا و استفاده کنید
https://www.aixploria.com/en/
پس برید و از استفاده از این ابزار لذت ببرید
موفق باشید 🌹
@srfirouzi_channel
سایت aixploria یک لیست عالی از ابزار های هوش مصنوعی (AI) هست که به شما کمک می کنند ، ابزار مورد نیاز خودتان را پیدا و استفاده کنید
https://www.aixploria.com/en/
پس برید و از استفاده از این ابزار لذت ببرید
موفق باشید 🌹
@srfirouzi_channel
AIxploria
AI Tools Directory & List of Best Free AI by Category (Top 10) | AIxploria
Access Aixploria, an AI tools directory featuring the largest list of AI available on the net. A ranking of the best AI to help you in your search.
Forwarded from Ninja Learn | نینجا لرن
📕 کتاب REST API Design Rulebook
📌 فصل دوم: Identifier Design with URIs
📍پارت: دوم
#کتاب
💎 URI Authority Design 💎
این بخش به نامگذاریهایی که باید برای قسمت "authority" (یا همان بخش اصلی آدرس) یک REST API استفاده شود، میپردازد.
⭕️ برای API هاتون باید از نامهای زیردامنهای منظم و یکسان استفاده کنید.
دامنه اصلی و اولین زیردامنه (مثلاً soccer.restapi.org) باید مشخصکننده مالک سرویس باشه. کل نام دامنه یک API باید یک زیردامنه به نام api اضافه کنه. برای مثال:
⭕️ برای پرتال توسعه دهندگان API هاتون باید از نامهای زیردامنهای منظم و یکسان استفاده کنید. خیلی از REST API ها یک وبسایت دارند که به عنوان پرتال توسعهدهندگان شناخته میشه و به کمک مستندات، انجمنها و ارائه کلیدهای دسترسی امن به API، کاربران جدید رو راهنمایی میکنه. اگر API شما یک پرتال توسعهدهنده داره، طبق عرف باید زیردامنهای به نام developer داشته باشه. برای مثال:
💎 Resource Modeling 💎
مسیر URI مدل منابع یک REST API رو نشون میده، به این صورت که هر بخش از مسیر که با اسلش جدا شده، به یک منبع منحصر به فرد در سلسله مراتب مدل اشاره میکنه. برای مثال، این طراحی URI:
نشون میده که هر کدوم از این URIها هم باید به یک منبع آدرسپذیر اشاره کنند:
مدلسازی منابع فرآیندیه که مفاهیم کلیدی API شما رو مشخص میکنه. این فرآیند شبیه مدلسازی داده برای یک پایگاه داده رابطهای یا مدلسازی کلاسیک در سیستمهای شیگرا است.
قبل از اینکه مستقیم وارد طراحی مسیرهای URI بشید، شاید بهتر باشه اول به مدل منابع REST API فکر کنید.
💎 Resource Archetypes 💎
هنگام مدلسازی منابع یک API، میتونیم با چند الگوی پایهای منابع شروع کنیم. مثل الگوهای طراحی، این الگوها به ما کمک میکنن که ساختارها و رفتارهای رایجی که در طراحی REST APIها وجود دارن رو به صورت منسجم بیان کنیم. یک REST API از چهار الگوی منبع مجزا تشکیل شده: سند (document)، مجموعه (collection)، فروشگاه (store)، و کنترلر (controller).
برای اینکه یک مدل منابع شفاف و ساده به مشتریان API منتقل بشه، یک REST API باید هر منبع رو فقط با یکی از این الگوها تطبیق بده. برای حفظ یکنواختی، وسوسه طراحی منابعی که ترکیبی از چند الگو هستن رو کنار بذارید. به جای این کار، بهتره منابع جداگانهای طراحی کنید که به صورت سلسلهمراتبی و/یا از طریق لینکها به هم مرتبط هستن، همونطور که در فصل ۵ توضیح داده شده.
هر کدوم از این الگوهای منبع در زیرمجموعههای بعدی به تفصیل توضیح داده شده.
@ninja_learn_ir
📌 فصل دوم: 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
Forwarded from Ninja Learn | نینجا لرن
📕 کتاب REST API Design Rulebook
📌 فصل دوم: Identifier Design with URIs
📍پارت: اول
#کتاب
💎 URIs 💎
توی وب API های REST از شناسههای منبع یکنواخت (URIs) برای آدرسدهی منابع استفاده میکنند.
امروزه، طراحیهای URI میتونن از شاهکارهایی باشن که مدل منبع API رو به وضوح نشون میدن،
مثل:
تا اونهایی که خیلی سختتر برای مردم قابل فهم هستن، مثل:
تیم برنرز-لی یه نکتهای درباره شفافیت URIs توی لیست "اصول معماری وب"ش ذکر کرده:
همونطور که توی فصل ۵ بحث شد، مشتریها باید از الگوی لینکدهی وب پیروی کنن و URIs رو به عنوان شناسههای غیرشفاف در نظر بگیرن. با این حال، طراحان APIهای REST باید URIsی طراحی کنن که مدل منبع API رو به وضوح به توسعهدهندگان احتمالی نشون بده.
این فصل یه سری قوانین طراحی برای URIs در APIهای REST رو معرفی میکنه.
💎 URI Format 💎
قوانینی که در این بخش ارائه شدهاند مربوط به فرمت یک URI هستند. استاندارد RFC 3986* سینتکس کلی URI رو به این شکل تعریف میکنه:
scheme: پروتکل یا روشی که برای دسترسی به منبع استفاده میشه، مثل http یا https.
authority: شامل اطلاعاتی مثل دامنه (domain) یا آدرس IP، و پورت سرور.
path: مسیر یا آدرسی که منبع خاصی رو در سرور مشخص میکنه.
query: پارامترهای اضافی که برای جستجو یا فیلتر کردن دادهها به URI اضافه میشن.
fragment: قسمتی از URI که به بخش خاصی از منبع اشاره میکنه، مثل یک بخش خاص از یک صفحه وب.
این قالب کلی به ما کمک میکنه تا ساختار URIها رو بهتر درک کنیم و بر اساس اونها، URIهایی طراحی کنیم که هم برای انسانها قابل فهم باشن و هم با استانداردهای وب سازگار باشن.
⭕️ از جداکنندهی اسلش (/) برای نشان دادن رابطهی سلسلهمراتبی استفاده کنید.
کاراکتر اسلش (/) در بخش مسیر (path) یک URI برای نشان دادن رابطهی سلسلهمراتبی بین منابع استفاده میشه. به عنوان مثال:
فرض کنید یک سایت دارید که شامل کشورها و شهرهاست. در این حالت، URI شما میتونه به این شکل باشه:
در این مثال، "iran" زیرمجموعهای از "countries" و "tehran" زیرمجموعهای از "iran" هست، که با استفاده از اسلش (/) این ساختار سلسلهمراتبی نشون داده شده.
این کار کمک میکنه تا URIها به شکلی ساختاریافته و قابل درک برای کاربران و توسعهدهندگان باشند.
⭕️ نباید از اسلش (/) درآخر URI ها استفاده کنید
وقتی اسلش (/) به عنوان آخرین کاراکتر در مسیر (path) یک URI قرار میگیره، هیچ ارزش معنایی اضافهای نداره و ممکنه باعث سردرگمی بشه. بنابراین، REST APIها نباید انتظار داشته باشند که URIها با یک اسلش انتهایی تموم بشند و نباید این نوع لینکها رو به کاربران ارائه بدهند.
بسیاری از اجزای وب و فریمورکها، این دو URI رو به طور یکسان در نظر میگیرند:
اما واقعیت اینه که هر کاراکتر در یک URI به شناسایی منحصر به فرد اون منبع کمک میکنه. دو URI متفاوت به دو منبع متفاوت اشاره میکنند. بنابراین، یک REST API باید URIهای تمیز و دقیق تولید کنه و نباید تلاشهای کاربران برای شناسایی منابع به شکل نادرست رو بپذیره.
البته، APIهای منعطفتر ممکنه کاربران رو به URIهایی بدون اسلش انتهایی هدایت کنند (همونطور که در قانون مربوط به استفاده از کد وضعیت 301 "Moved Permanently" برای جابجایی منابع توضیح داده شده).
⭕️ برای بهبود خوانایی URIها از خط تیره (-) استفاده کنید
برای اینکه URIهاتون رو برای افراد قابل فهم و قابل اسکن کنید، از کاراکتر خط تیره (-) استفاده کنید تا خوانایی نامها در بخشهای طولانی مسیر (path) بهتر بشه. هر جایی که در زبان انگلیسی از فاصله یا خط تیره استفاده میکنید، در URI هم باید از خط تیره استفاده کنید. به عنوان مثال:
این کار باعث میشه که URIها هم از نظر ظاهری بهتر و هم از نظر فهم و کاربرد راحتتر بشند.
📌 فصل دوم: 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ها هم از نظر ظاهری بهتر و هم از نظر فهم و کاربرد راحتتر بشند.
#کتاب
Forwarded from Ninja Learn | نینجا لرن
📕 کتاب REST API Design Rulebook
📌 فصل اول: معرفی (Introduction)
📍پارت: چهارم (پارت آخر فصل اول)
#کتاب
💎 WRML 💎
من (نویسنده کتاب) یه چارچوب مفهومی به نام Web Resource Modeling Language (WRML) اختراع کردم که به طراحی و پیادهسازی REST API ها کمک میکنه. WRML، که به صورت "ورمل" تلفظ میشه، اول به عنوان یه تکنیک برای رسم مدل منابع به وجود اومد که از یه سری اشکال ساده برای نمایش هر کدوم از الگوهای منابع استفاده میکنه.
دامنهی WRML با ایجاد نوع رسانهای به نام
در فصلهای ۵ و ۶ متوجه میشی که خیلی از قوانین با مثالهایی که از JSON استفاده میکنن، توضیح داده شدن. JSON یه فرمت مهمه که مزایای زیادی داره، مثل پشتیبانی بومی از جاوااسکریپت، پذیرش تقریبا جهانی، و سینتکس آشنا. اما JSON به تنهایی ساختارهای یکسانی برای بعضی از مهمترین مفاهیم REST API مثل لینکها، روابط لینکها، و اسکیمها ارائه نمیده. قوانین توی فصلهای "نمایش هایپرمیدیا" و "نمایش اسکیم" از WRML استفاده میکنن تا فرمهای نمایشی مبتنی بر JSON رو برای این ساختارهای اصلی نشون بدن.
در نهایت، فصل ۷ تأکید میکنه که یکنواختی در طراحی API فقط یه موضوع تئوری نیست؛ بلکه میتونه زندگی برنامهنویسا رو بهتر کنه و به ما ابزاری غنی بده تا با استفاده از اونها REST API های بهتری طراحی و توسعه بدیم.
✅ خلاصه
این فصل خلاصهای از اختراع و تثبیت وب رو ارائه داد. همچنین به معرفی رویکرد قوانینمحور کتاب و چارچوب مفهومی WRML پرداخت، که ایدههای اون به طراحی یکپارچه REST API کمک میکنن. فصلهای بعدی بر این پایه استوار میشن تا به ما کمک کنن که از REST در طراحی API استفاده کنیم.
جدول ۱-۱ هم خلاصهای از اصطلاحات جدیدی که توی این فصل معرفی شدن رو ارائه میده.
@ninja_learn_ir
📌 فصل اول: معرفی (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
#کتاب