این بدبخت هم که اینجا دکور بود

امنیت سرور ها

زمانی که می‌خواید یک Node.js process ران کنید ولی از امن بودنش خیلی مطمئن نیستید ، می‌تونید از ویژگی Permission Model که از آپدیت v23.5.0 به بعد دیگه آزمایشی نیست استفاده کنید. و با فلگ هایی که در اختیارتون قرار میده ، برنامه رو به صورت محدود شده ران کنید.

مثال برای File System :

node --allow-fs-read=/folder1/ //app.js -> برای دسترسی خواندن

node --allow-fs-write=/folder2/ //app.js -> برای دسترسی نوشتن


برای Child Process ، Worker Threads ، WASI و Addons هم می‌تونید محدودیت ست کنید.

از هوش مصنوعی Claude(چون هیستوری اش فعال نبود و نمی‌دونست اهل کدوم کشورم) پرسیدم پر پتانسیل ترین کشور های دنیا از همه لحاظ (منابع ، تاریخ ، موقعیت جغرافیایی و...) چه کشور هایی هستند؟

نتیجه اش باحال بود پیشنهاد می‌کنم حتما بخونیدش.

https://claude.ai/share/866422cb-6b05-48d7-a696-c0411b99174f

زمانی که توی پروژه‌های TypeScript کار می‌کنید، گاهی لازمه از روی یک Type، نسخه‌های تغییر یافته یا محدودشده‌ای بسازید.
برای همین TypeScript مجموعه‌ای از ابزارها به نام Utility Types در اختیارتون قرار میده که باهاشون می‌تونید Typeهای جدید رو از Typeهای موجود مشتق کنید.

چند تا از مهم‌ترین Utility Type ها رو ببینیم:

1-Partial<T>
تمام پراپرتی‌های یک Type رو اختیاری می‌کنه.
معمولاً برای آپدیت بخشی از داده استفاده میشه.

type User = { name: string; age: number }
type UserUpdate = Partial<User>

const data: UserUpdate = { age: 25 }

2-Pick<T, K>
فقط بعضی از کلیدهای Type رو نگه می‌داره.

type User = { id: number; name: string; email: string }
type PublicUser = Pick<User, "id" | "name">

در این مثال، نوع جدید فقط شامل id و name میشه.


3-Omit<T, K>
برعکس Pick کار می‌کنه و کلیدهای مشخص‌شده رو حذف می‌کنه.

type PrivateUser = Omit<User, "email">

4-ReturnType<F>
نوع خروجی تابع رو استخراج می‌کنه.

function getUser() {
  return { id: 1, name: "Reza" }
}
type User = ReturnType<typeof getUser>

‏Utility Type ها مخصوصاً زمانی مفیدن که بخواید Type های منعطف‌تری بسازید بدون اینکه ساختارهای جدید رو از صفر تعریف کنید.
باعث میشن کد تمیزتر، قابل‌نگهداری‌تر و کمتر تکراری بشه.

#ts

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

من الان با این syntax error چیکار کنم؟

ما Developer ها به Magic عادت داریم. بیشتر وقت ها کدی که مینویسیم فقط میخوایم کار کنه. اما چطور کار کردن اون کد خیلی اهمیتی نداره تا وقتی که کدمون کار میکنه. حالا چه به صورت جادویی کار کنه چه با جزئیات کامل بدونیم پشت پرده چخبر هست. گاها بعضی از این جادو ها اینقدر پیچیده و ترسناک به نظر میان که اصلا بهشون نزدیک نمیشیم. یکی از این Magic ها Promise ها در #JavaScript هست. اکثرا فکر میکنیم یک چیزی هست که داخل گوشت و وجود #JavaScript فرو رفته و به هیچ عنوان نمیشه تغییرش داد یا اگر هم بشه خیلی سخت هست. کاری به پیاده سازی اصلیش امروز نداریم. امروز بعد از این مقدمه طولانی میخواهیم باهم یاد بگیرم چطور یک Object بسازیم که شبیه به Promise عمل میکنه. یعنی میتونیم await کنیم اون رو با وجود این که اصلا اون Promise نیست و یک Object ساده هست. به این کد پایین دقت کنید.

const thenable = {
  then(resolve, reject) {
    setTimeout(() => resolve("Hello from thenable!"), 1000)
  },
}

const txt = await thenable
console.log(txt)

معمولا اولین واکنش افراد به این تکه کد "WTF" هست. داستان از این قرار هست که خیلی قبل تر از این که Promise ها به صورت استاندارد وارد #JavaScript بشن پیاده سازی های مختلف ازش وجود داشته و هرکدوم implemention detail خاص خودشون رو داشتن ولی طی گذر زمان بلاخره رسیدن به این interface که الان داریم هر روز باهاش کار میکنیم ( تقریبا شبیه به وضعیت decorator ها و پروپزوال مربوط بهش ). بزارید یکم بیشتر وارد داستان بشیم.

برای این که بتونیم یک object رو await کنیم لزوما نیازی نداره حتما یک instance از Promise باشد. بلکه هر object که Promise-like باشد میتواند await بشود. این تعریف دقیقا تعریف Duck-typing هست که قبلا مفصل درموردش حرف زدیم. حالا سوال پیش میاد که Promise-like یعنی چی؟
- هر class که thanable interface را implement کند میتوان آن را await کرد.

پس میتونیم نتیجه بگیریم که همه Promise ها thenable هستند ولی همه thenable ها Promise نیستند.

حالا میرسیم که thanable interface چیست؟ در ساده ترین حالت دقیقا مثال بالا رو در نظر بگیرد. یک object یا class که then method رو که با دوتا argument که هردو callback هستن یکی برای وقتی که reject شده و یکی برای وقتی resolve میشه invoke میشود و ما میتونیم با اون دوتا رفتاری که Promise-like هست رو از خودمون نشون بدیم.

حالا این ویژگی به ما اجازه داده که پکیج های معروفی مثل promise-retry ببینیم یا حتی یکم تلاش کنیم به کمک Promise-like ها در ES5 بتونیم چیزی شبیه بهش رو داشته باشیم که البته این موضوع خودش یک بحث دیگس اگر دوست دارید نگاهی به promise-polyfill یا babel-polyfill بندازید.

این هم پست مربوط به duck typing به نظرم نگاهی بندازید:
https://news.1rj.ru/str/NodeMaster/128

دیشب گفتن که بگم چطور کار می‌کنه که اونو الان توضیحاتش رو می‌نویسم.

سیستم‌عامل بلادرنگ مثل یک جور مغز فوق‌منظم برای سخت‌افزاره. فرقش با سیستم‌عامل‌های معمولی اینه که همه چیز براش حول محور زمان و اولویت می‌چرخه. یعنی مهم نیست چند تا کار داره انجام می‌ده، همیشه می‌دونه کدوم کار مهم‌تره و باید دقیقاً الان انجام بشه.

تو یه RTOS، برنامه‌ها به‌جای اینکه مثل یه صف طولانی پشت سر هم اجرا بشن، به شکل تسک (Task) یا ترد (Thread) جدا جدا تعریف می‌شن. هر تسک یه اولویت خاص داره. مثلاً اگه داری با یه ربات کار می‌کنی، تسک مربوط به کنترل موتور باید خیلی سریع‌تر از تسک نمایش چراغ LED اجرا بشه. سیستم‌عامل بلادرنگ اینو می‌فهمه و به کمک یه چیز به اسم Scheduler (زمان‌بند) همیشه تصمیم می‌گیره الان نوبت کدوم تسکه.

زمان‌بند تو RTOS با سیستم‌عامل‌های معمولی خیلی فرق داره. تو سیستم‌هایی مثل لینوکس یا ویندوز، scheduler ممکنه بگه «انشالله از شنبه». ولی سیستم‌عامل بلادرنگ کار امروز رو به فردا نمیسپاره :))))

از نظر RTOS همه چیز باید دقیق و قابل پیش‌بینی باشه. مثلاً می‌دونه این تسک باید هر ۱۰ میلی‌ثانیه یه بار اجرا بشه، و دقیقاً همون‌قدر هم اجراش می‌کنه، نه یه میلی‌ثانیه زودتر، نه دیرتر.

این دقت با چیزی به اسم تایمر سیستم (System Timer) تأمین می‌شه. این تایمر مثل یه ضربان قلب، هر چند میکروثانیه یه بار تیک می‌زنه و به زمان‌بند می‌گه وقتشه چک کنی ببین نوبت کیه. اگه تسک جدیدی با اولویت بالاتر آماده باشه، سیستم تسک فعلی رو قطع می‌کنه و اون یکی رو فوری اجرا می‌کنه. به این می‌گن Preemption، یعنی پیش‌دستی کردن در اجرا. این کار باعث می‌شه تسک‌های مهم هیچ‌وقت منتظر نمونن و بلافاصله اجرا بشن.

یه RTOS همیشه یه سری تسک با وضعیت‌های مشخص داره. بعضی تسک‌ها در حال اجرا هستن (Running)، بعضی‌ها منتظر یه رویداد یا دستورن (Waiting)، بعضی‌ها هم خوابیدن تا یه تایمر تموم بشه (Sleeping). سیستم این وضعیت‌ها رو با سرعت خیلی بالا مدیریت می‌کنه تا هیچ تاخیری پیش نیاد. هر لحظه می‌دونه کدوم تسک آماده‌ست، کدوم منتظره، و کدوم باید الان اجرا بشه.

یه بخش خیلی مهم دیگه تو RTOS، وقفه‌ها (Interrupts) هستن. وقتی یه سخت‌افزار مثل یه سنسور یا پورت سریال یه سیگنال می‌فرسته، RTOS اون سیگنال رو نادیده نمی‌گیره یا نمی‌ذاره در نوبت بمونه. بلافاصله می‌ره سراغش، چون ممکنه اون اتفاق حیاتی باشه. برای همین تو RTOS، مدیریت وقفه‌ها فوق‌العاده دقیق و با اولویت بالا انجام می‌شه. حتی ممکنه یه وقفه، یه تسک در حال اجرا رو قطع کنه و خودش رو اجرا کنه، بعد دوباره برگرده به همون تسک قبلی.

توی یه RTOS همه چیز بر پایه‌ی قطعیت و پیش‌بینی‌پذیری ساخته شده. زمان اجرای هر تسک معلومه، اولویت‌ها ثابته، وقفه‌ها سریع جواب داده می‌شن و هیچ چیز تصادفی نیست. به همین خاطر می‌تونی مطمئن باشی که وقتی گفتی "موتور رو بعد از ۵ میلی‌ثانیه خاموش کن"، دقیقاً بعد از همون ۵ میلی‌ثانیه خاموش می‌شه، نه بیشتر، نه کمتر. این دقت همون چیزیه که RTOS رو برای سیستم‌های بحرانی مثل هواپیما، دستگاه‌های پزشکی، خودروها، و ربات‌ها ضروری می‌کنه.


@SohrabContents