هم اکنون با این ابزار جدید میتونید #TypeScript رو به #Lua تبدیل کنید.
اگر براتون سوال هست که کجا میتونه کاربرد داشته باشه این میتونه باشه که با #Lua میتونید به عنوان مثال برای #Redis اسکریپت بنویسید و حالا میتونید این کار رو بدون یاد گرفتن #Lua و با نوشتن #TypeScript و گرفتن خروجی #Lua انجام بدید. هرچند من شخصا طرفدار این موضوع نیستم ولی جالبه.

https://typenoscripttolua.github.io/

#NodeWeekly

به این خط ساده و کوچک دقت کنید، توانایی این رو داره هرپروژه #FrontEnd و #BackEnd که با #NodeJS توسعه داده شده رو تبدیل به جهنم کنه.

throw 1;

اگر در #TypeScript براتون سوال پیش اومده که چرا در try catch statement تایپ err نامشخص هست، دقیقا بخاطر این موضوع هست. به این دلیل که هر نوع Object رو میشه throw کرد (این خیلی ترسناکه) و چون #JavaScript مفهومی به اسم Compile Time Error نداره و با توجه به طبیعت Dynamic و البته مفسری که #JavaScript داره منطقی هست که شما وقتی try catch استفاده میکنی type برای error تا زمان runtime مشخص نباشه. با مثال پایین بیشتر به عمق مسئله پی میبرید.

try {
  throw { hoo: "Pop up from stack , NodeMaster" };
} catch (err /* type => unknown */) {
  console.log(err);
}

معمولا بعضیا با استفاده از type cast تایپ error رو تبدیل به Error میکنن مثل کد زیر که این به نوع خودش میتونه یک فاجعه دیگه باشه ( آخه نابغه اگر تایپ مشخص بود که Error هست #TypeScript همون اول خودش Error میزاشت و نیاز به Type Cast نبود دیگه)

try {
  throw { hoo: "Pop up from stack , NodeMaster" };
} catch (err) {
  console.log((err as Error).message);  // WTFFFFFFFFF !!!!
}

خب حالا سناریو های بد رو دیدم چطور جلوگیری کنیم؟ در پروژه های #FontEnd تنها روش خیلی خوبی که وجود داره استفاده از instanceof هست در #NodeJS برای #BackEnd هم میشه از این روش استفاده کرد ولی یک تکنیک دیگه وجود داره که اون بیشتر برای سناریوهای خیلی خاص #NodeJS هم کاربردی هست.

try {
  throw { hoo: "Pop up from stack , NodeMaster" };
} catch (err) {
  if (err instanceof Error) {
    console.error("it's valid error object", err);
  } else {
    console.error("WHAT THE F IS THIS ???", err);
  }
}

برای پروژه های #NodeJS در std مربوط به Node یک فانکشن کمکی هست به اسم isNativeError که همین کار instanceof رو میکنه. حالا سوال پیش میاد که چرا باید از این استفاده کنیم؟ در حالت هایی به عنوان مثال استفاده از "node:vm" و ایجاد یک context جدید میتونه دردسر ساز بشه و instanceof نتونه تشخیص بده Error رو که نتایجش هم مشخصه. نکات دیگه ای هم وجود داره که پیشنهاد میکنم داکیومنت مربوط به این بخش رو بخونید کامل با مثال ساده توضیح داده.

import { types } from "node:util";
try {
  throw { hoo: "Pop up from stack , NodeMaster" };
} catch (err) {
  if (types.isNativeError(err)) {
    console.error("it's valid error object", err);
  } else {
    console.error("WHAT THE F IS THIS ???", err);
  }
}

حالا یک سوال دیگ شاید براتون پیش بیاد که چرا اینقدر بدبینانه به مسئله نگاه میکنیم؟
تو دنیایی که #NPM وجود داره اعتماد به پکیج های 3RD Party گاهی اوقات میتونه گرون تموم بشه. شاید اون پکیج که استفاده میکنید این داستان رو رعایت نکرده باشه. پس بهتره ما دقت کنیم تا از runtime ارور های نصف شب جلوگیری کنیم و با آسوده بخوابیم.

#Work
این تیم دنبال #NodeJS میگرده اگر دوست داشتید رزومه خودتون رو بفرستید.

https://jobvision.ir/jobs/job-detail/770925?ReferrerJobPosition=8&row=3&pageSize=30&keyword=node&searchId=385378404706959333

داشتم طبق عادت stackoverflow میگشتم دنبال نکته جدید برای یادگیری.
به یک سوال خوردم و وقتی روش وقت گذاشتم حس کردم یک باگ روی #NodeJS هست و رفتار منطقی نمیبینیم و خب بقیه هم ظاهرا به همین نکته رسیدن اون سوال باعث ایجاد یک issue روی #NodeJS core شد اگر دوست داشتید نگاهی به سوال بندازید و برسیش کنید خیلی جذاب بود.

سوال:
https://stackoverflow.com/questions/78630248/how-to-properly-abort-node-readline-promise-question

گیت هاب:
https://github.com/nodejs/node/issues/53497

یک Pattern وجود داره که خیلی درموردش صحبت نمیشه در اکوسیستم #JavaScript چه پروژه های #FrontEnd و چه #Backend که با #NodeJS و بقیه runtime ها توسعه داده شده باشن. این پترن خیلی ساده هست. استفاده نکردن ( یا حداقل استفاده ) از Anonymous function ها میباشد.

حالا سوال پیش میاد چرا از این پترن باید استفاده کنیم؟
وقتی دارید برنامه توسعه میدین و به نوعی چه توسط خودتون یا Framework که استفاده میکنید با فرایند IOC درگیر هستید مثل #React یا حتی #Express و ... اگر سایز پروژه بزرگ باشه برای پیدا کردن Bug ها به هیچ عنوان تکنیک console.log راه بهینه ای نیست. و معمولا از ابزار ها و تکنیک های مختلف در کنار هم استفاده میشن تا این فرایند راحت تر باشه. در کنار این مفاهیم لاگ کردن Error ها و stack trace مربوط بهشون خیلی مهم هست و خیلی کمک میکنه تا scope مربوط به به باگ رو کوچک تر کنیم و سریعتر بتونیم باگ رو پیدا کنیم.

با استفاده زیاد از Anonymous function ها که معمولا بیشتر در هنگام arg برای پاس دادن به عنوان callback استفاده میشن، stack trace شکل خوبی نخواهد داشت و اگر زیاد استفاده بشه حتی stack trace میتونه کاملا بی مصرف بشه و با این کار یکی از عناصر خیلی مهم برای debug کردن رو از دست میدیم. به مثال زیر توجه کنید.

function iocContainer(cb) {
    cb()
}
iocContainer(() => { throw new Error("ugly stack trace") })

    at /home/imanhpr/codes/main.js:6:28
    at iocContainer (/home/imanhpr/codes/main.js:2:5)
    at Object.<anonymous> (/home/imanhpr/codes/main.js:6:1)

اینجا سایز پروژه کوچک هست و راحت میشه Error رو پیدا کرد چون جزیات زیادی در stack وجود نداره و کد framework هم در نظر گرفته نشده. اما توجه داشته باشید که اون خط آخر یعنی Object.anonymous در شرایط فشار باگ روی production خیلی میتونه ترسناک باشه.یک نکته که حتی میتونه وحشتناک تر کنه داستان رو پروژه #TypeScript بدون source map و اگر به این ترکیب esbuild هم اضافه بشه جای صحبتی اصلا باقی نمیمونه.

حالا با یک مثال واقعی تر و خیلی ساده این موضوع رو برسی میکنیم

const express = require("express")

const app = express()

app.get("/", (req, res) => {
    throw new Error("ugly error")
})

app.listen(3000)

Error: ugly error
    at /home/imanhpr/codes/main.js:6:11
    at Layer.handle [as handle_request] (/home/imanhpr/codes/node_modules/express/lib/router/layer.js:95:5)
    at next (/home/imanhpr/codes/node_modules/express/lib/router/route.js:149:13)
    at Route.dispatch (/home/imanhpr/codes/node_modules/express/lib/router/route.js:119:3)
    at Layer.handle [as handle_request] (/home/imanhpr/codes/node_modules/express/lib/router/layer.js:95:5)
    at /home/imanhpr/codes/node_modules/express/lib/router/index.js:284:15
    at Function.process_params (/home/imanhpr/codes/node_modules/express/lib/router/index.js:346:12)
    at next (/home/imanhpr/codes/node_modules/express/lib/router/index.js:280:10)
    at expressInit (/home/imanhpr/codes/node_modules/express/lib/middleware/init.js:40:5)
    at Layer.handle [as handle_request] (/home/imanhpr/codes/node_modules/express/lib/router/layer.js:95:5)

این مثال کیلومتر ها با پیچدگی پروژه های production فاصله داره اما همین کد ساده نشون میده چقدر توجه به این نکته میتونه ساعت ها از وقت شما نجات بده و کار کم استرس
تری هم تجربه کنید. مشکل دقیقا خط اول stack trace هست که هیچی ازش وجود نداره ( در این مثال خوش شانسیم که خطی که این اتفاق افتاده دقیقا اشاره داره به همون callback ما ولی همیشه اینطور نیست )

برای داشتن زندگی شیرین تر کافیه کمتر از Anonymous function ها چه به شکل arrow و چه با function keyword استفاده کنید. و برای function ها نام مناسب انتخاب کنید. مثل سناریو پایین که rootHandler رو داریم.

app.get("/", function rootHandler(req, res) {
    throw new Error("ugly error")
})
// OR
const rootHandler = (req, res) => {
    throw new Error("ugly error")

}
app.get("/", rootHandler)

Error: ugly error
    at rootHandler (/home/imanhpr/codes/main.js:6:11)
    at Layer.handle [as handle_request] (/home/imanhpr/codes/node_modules/express/lib/router/layer.js:95:5)

حالا چند نکته باید در نظر بگیرید.
- تفاوت arrow function و function keyword رو بدونید گاهی ممکنه دردسر ساز بشه.
- اگر از #TypeScript استفاده میکنید از اهمیت source map هرگز غافل نشید.

#Tip

فرض کنید یک وب سایت فروشگاهی دارید و در حال توسعه API هستید که میخواید وضعیت سفارش ها رو در پنل ادمین نمایش بدین. کارفرما از شما میخواد که Status های درحال انتظار در اول قرار بگیره و بقیه هم بعد از اون. در این حالت با این Query کارتون رو میتونید راه بندازید.

ORDER BY 
    CASE WHEN Status = 'WAIT' THEN 0 ELSE 1 END,
    Date DESC

#Tip #SQL

در حال مطالعه داکیومنت Tron هستم برای کار با Smart Contract ها و ... که یک نکته خیلی ریز در اصل یک کلمه خیلی توجهه من رو جلب کرد. به عکس بالا دقت کنید، مخصوصا به بخش highlight شده، مخصوصا به کلمه "compatible". این کلمه خیلی کلمه مهمی هست.

حالا بخوام یکم Context بدم درمورد موضوع این هست که Smart Contract های ERC-20 که روی شبکه ETH هستن باید کدشون کاملا سازگار باشه با TRC-20 که روی شبکه Tron هست. و اینجا اگر دقت کنیم دوباره میرسیم به این جمله معروف.
"program to interfaces, not implementations"

چند ماه پیش درمورد دلیل این که چرا درک این جمله اینقدر مهمه صحبت کردم و پست هایی هم داشتیم. حالا داستان "compatible" چیه ؟ اگر شما برید کد Smart Contract مربوط به USDT رو چک کنید متوجه کلمه های ERC میشید که این مربوط به شبکه ETH هست ولی روی شبکه Tron.
خیلی ساده بخوام بگم ما مفهوم این جمله رو داریم در Scale خیلی بزرگ میبینیم و سرنخ این موضوع در حد یک کلمه همینقدر ریز هست.

این هم لینک اون پست. دوستان واقعا زندگی برنامه نویسی شما بعد از درک این مفهوم به دو بخش تقصیم میشه. قبل و بعد از درک این موضوع.
https://news.1rj.ru/str/NodeMaster/137

به تازگی نسخه جدید LTS یعنی 20.15 برای #NodeJS منتشر شده.
یکی از ویژگی های کاربردی که اضافه شده مربوط به "node:test" هست. قابلیت test plan هست

test('top level test', t => {
  t.plan(2);
  t.assert.ok('some relevant assertion here');
  t.subtest('subtest', () => {});
});

به این صورت کار میکنه که اگر تعداد subtest ها و یا assertion ها برابر با plan نباشه تست به خطا میخوره و این موضوع در unit test خیلی میتونه کاربردی باشه به دلیل این که میتونه تست ها رو strict تر کنه.

موضوع بعدی اضافه شدن یک flag جدید هست

--inspect-wait

یکی از مهمترین flag های #NodeJS در حقیقت خانواده flag های inspect هست. حالا سوال پیش میاد چرا؟ با کمک این فلگ ها میتونید با استفاده از ابزار های کمکی مثل chrome dev tools که یک debugger مربوط به انجین V8 داره به جنگ Bug ها و Bottleneck ها برید. برای Bottleneck یک ابزاری که اینجا در دسترس هست flamegraph هست که فارغ از زبان تو هر زبان برنامه نویسی میتونی این مدل نمودار رو ببینی ( لازمه بگم کسایی که flamegraph بلدن بخونن واقعا آدم های قابل احترامی هستن ).
یکی دیگه از بزرگترین و مهمترین ابزار هایی که کمک میکنه و میتونه ساعت ها زندگیتون رو نجات بده Heap Profiler هست. کابوس هر برنامه نویس #NodeJS قطعا Memory leak هست و پیدا کردنش خیلی سخته. اما اگر از Heap Profiler درست استفاده بشه خیلی سریع میشه Memory leak ها رو پیدا کرد.

چندماه هست دوست دارم درمورد inspect عمیق بشیم ولی متاسفانه فرصتش هیچ وقت برام پیش نیومده. ولی قطعا یک روز این موضوع رو عمیق میشیم.

#Update

یک خورده دارم #React مرور میکنم برای پروژه شخصی. یک موضوعی که به ذهنم اومد این هست که چطور موقع هندل کردن event ها با handler function ها چطور stack trace تمیزی داشته باشیم.
در این پست درمورد این موضوع و این که چطور stack trace تمیزی داشته باشیم با مثال #Express روی #NodeJS صحبت کردیم.
https://news.1rj.ru/str/NodeMaster/228
در این پست هم راجع به Reflection اشاره ای کردیم.
https://news.1rj.ru/str/NodeMaster/121

حالا شما component زیر که خیلی ساده هست رو در نظر بگیرید

function SimpleComp() {
  function clickHandler() {
    console.log("handler fn :", clickHandler.name);
  }
  return <button onClick={clickHandler}>click here!</button>;
}

بزارید همین اول بگم این نکته شاید خیلی زیاده روی باشه و نیاز نباشه ولی خب میتونه برای درک بهتر Reflection درنظر گرفتش. تا اینجا باتوجه به چیزایی که میدونم stack trace خوبی خواهیم داشت به دلیل این که clickHandler اسم داره.
سناریویی رو در نظر بگیرید که دارید روی یک سری دیتا loop میزنید و برای هر Entity که دارید یک clickHandler ایجاد میکنید. سوال پیش میاد وقتی روی یکی از این function ها کلیک و call میشه چطور بدونیم کدوم call شده دقیق؟
۱. راه حل ساده تر و همیشه جواب log کردن هست.
۲. راه حل پیچیده تر کمک از Reflection و تغییر اسم function در runtime.
دوستان لزوما نیازی نیست از Reflection استفاده کنید. با log کردن صحیح نیازی اصلا ندارید و فقط این روش پیچدگی بیهوده اضاف میکنه و صرفا برا عمیق شدن داریم میریم جلو.

function SimpleComp({ id }) {
  function clickHandler() {
    console.log("handler fn :", clickHandler.name);
  }

  Reflect.defineProperty(clickHandler, "name", {
    value: clickHandler.name + "_" + id,
  });
  return <button onClick={clickHandler}>click here!</button>;
}

در اینجا من اومدم به اسم فانکشن Id که به عنوان prop اومده رو در runtime اضافه میکنم و خب این دقیقا معادل همچین چیزی میشه.

function clickHandler_2 (){}

اسم فانکشن به صورت عادی یکی از چیزایی هست که زمان compile time ( یا اینجا dev time میشه بهش گفت هرچند خیلی مرسوم نیست) مشخص میشه و خب وقتی چیزی رو در این زمان داشته باشیم dynamic کردنش نزدیک به غیرممکن هست.

حالا اینجا Reflection بهمون کمک میکنه که در runtime یک چیزی که به صورت عادی دردسترس نیست رو تغییر بدیم مثل name atter برای function ها که در این مثال دارید میبینید و دقیقا این موضوع معادل کد clickHandler_2 هست با این تفاوت که در runtime ایجاد میشه و نه compile time.

#Tip

دوستان که با من کم و بیش درمورد roadmap و یا نظرم رو درمورد مسیرشون پرسیدن همه میدونن من چقدر شخصا روی مبحث database و db design خیلی تاکید زیادی دارم.

در این توییت یک کتاب که مدتی هست دارم میخونم معرفی کردم و نکاتی هم کلی گفتم.
https://x.com/imanhpr_media/status/1808176854945177927?t=6qvq2I-HaKufcJh4a0KGSQ&s=19

این کتاب خیلی کتاب با ارزشی هست و برا من حکم یک سلاح مخفی داره و خب باعث competitive advantage زیادی برای من شده.

#Book

باورم نمیشه مفهوم به این عمیقی در CS این روزا ها میشه بهش نگاه سیاسی داشت.
این توییتم درمورد halting problem توضیح دادم. خیلی زیاد یادم نیست در این مورد و خیلی خلاصه و ساده سعی کردم توضیح بدم که هر خواننده ای بتونه بخونه. ولی در کل برای شما میتونه یک سرنخی باشه برای عمیق تر شدن در این موضوع.
https://x.com/imanhpr_media/status/1808831653323608501
#CS #Tip

ظاهرا به صورت std قراره sqlite به #NodeJS اضافه بشه. خبر جالبی هست.
اینجا میتونید اطلاعات بیشتر رو دنبال کنید.
https://github.com/nodejs/node/pull/53752
#NodeWeekly

من شخصا به عنوان یک #Python Hater دو آتیشه هستم.
ولی یک چیزی داره و عجیب خوب هست. حداقل من تا حالا شبیهش رو داخل هیچ اکوسیستم دیگه ای ندیدم و اگر شبیهش رو میشناسید معرفی کنید خوشحال میشم.

این ویژگی خیلی واقعا خفن pickle std برای #Python هست. در حقیقت pickle یک serialization format مثل #JSON هست و مثل #Protobuf یک فرمت binaray هست. حالا سوال پیش میاد چه نکته ای داره.
شما به pickel هر object در اکوسیستم #Python رو میتونید serialize کنید. هر Object با تمام پیچدگی ها custom که داره. بزارید با مثال توضیح بدم.
تصور کنید یک JSON دارید و اون رو میخواید map کنید به یک class و خب معمولا با Factory ها و به شکل های مختلف این اتفاق میافته.

class User {
  constructor(name) {
    this.name = name;
  }
  static FromJsonString(input) {
    const result = JSON.parse(input);
    return new User(result.name);
  }
}

const runTimeInput = '{"name":"imanhpr"}';
const user = User.FromJsonString(runTimeInput);

console.log(user instanceof User);
console.log(user.name);

همه چی خیلی منطقی کار میکنه در این سناریو. نکته جالب که اینجا و توجه بهش جالبه این هست که در اینجا به صورت ذاتی هیچ metadata وجود نداره که مشخص بشه مقدار runTimeInput واقعا از جنس User هست و معمولا با استفاده از validation های مختلف و factory متد ها باید مشخص کنیم. اگر بخوایم یک سناریو دیگ رو برسی کنیم که یکم پیچیده تر باشه. شما به هردلیل منطقی یا غیرمنطقی تصمیم داری یک function که در نهایت یک object هست رو serialize کنید. چطور این کار میکنید؟

function hello() {
  console.log("hooo");
}
console.log(JSON.stringify(hello));

باتوجه به این که در #JSON به طور کلی هیچ طوره فرمت استانداردی وجود نداره برای این کار منطقی هست کد بالا کار نکنه. ( البته با trick همین کد بالا رو میتونید کاری کنید که بشه ولی کاری به اون سناریو نداریم :) )
یک سناریو پیچیده تر اینه که شما یک object داشته باشید که property denoscriptor های اون رو دست کاری کردین چطور میخواین بدون ست کردن flag یا نشانه در هنگام serialize کردن و بعد از دریافت همون object متوجه بشید که property denoscriptor رو چطور باید ست کنید.

کلا بخوام خلاصه و جمع بندی کنم هرچیزی که مختص object هست که در runtime وجود داره مثل انواع reflection ها و property denoscriptor و method ها و ... .
اینجا هست که pickel خودش رو نشون میده.

import pickle

class NumberOne:
    def __get__(self, obj, objtype=None) :
        return 1


class User:
    __name = "iman"
    one = NumberOne()

    @property
    def name(self):
        print("hello from getter")
        return self.__name
    
    def __eq__(self, value: object) -> bool:
        if isinstance(value , User) and self.__name == value.__name:
            return True
        return False
    
    def __str__(self) -> str:
        return f'User(name={self.__name})'

def hello():
    print("hello from function")

# instance sterilization
user_instance_bin = pickle.dumps(User())
run_time_user = pickle.loads(user_instance_bin)
print("user instanceof User :",isinstance(run_time_user , User))
print("user object :" ,  run_time_user)
print("equality check :" , run_time_user == User())
print("getter invocation :" , run_time_user.name)

# function sterilization
function_bin = pickle.dumps(hello)
run_timefn = pickle.loads(function_bin)
run_timefn()

# class sterilization
cls_bin = pickle.dumps(User)
runtime_cls = pickle.loads(cls_bin)
print("class check:" , issubclass(runtime_cls , User))

# << Exciting part >>
print("WTF:",run_time_user.one)

در اینجا شما هر جسم قابل لمسی رو در #Python میتونید serialize کنید و مستقیم با خوندن همون data یک object قابل لمس در runtime با تمام metadata ها دریافت کنید. از class گرفته تا یک gatter method که با decorator هست تا انواع magic method ها یا به قول #Pythonic ها dunder method.
از همه جالب تر اون بخش آخر هست که یک Python Denoscriptor رو هم کنار object های User گذاشتیم و میبینیم اون هم به صورت کامل میبینیم. اگر بخوام خلاصه در یک جمله توضیح بدم رسما با اینکار انگار از یک object دارید فایل exe میسازید به جای یک برنامه بزرگ!

نکته بعدی این که این pickel استاندارد مربوط به کد های python هست و جای دیگ تقریبا میشه گفت کاربردی نداره.

https://docs.python.org/3/library/pickle.html

خدمت شما بگم #Deno 1.45 به تازگی منتشر شده. یکی از نکات خوبی که من در این آپدیت دیدم قابلیت Monorepo هست که اضافه شده.
و البته std هم داره نزدیک به stable شدن میشه.
و صد البته با فعال کردن flag زیر میتونید دسترسی به ویژگی های جدید #Deno در ورژن 2 داشته باشید.

DENO_FUTURE=1

#Update

به نسخه LTS آینده یعنی 22 در آپدیت 22.5 پکیج node:"sqlite اضافه شد. البته این نکته قابل ذکر هست که این پکیج stable نیست و در حال توسعه میباشد.
https://nodejs.org/docs/latest/api/sqlite.html

درود دوستان وقت همگی بخیر باشه.
یک مدتی هست فعالیت کانال کم شده و شخصا خیلی فعالیتی ندارم. خواستم بگم. یک مدت کوتاهی میخوام استراحت کنم ولی بعد دوباره با هم ادامه خواهیم داد. امیدوارم موفق باشین❤️

درود و وقت بخیر.
مدتی فعالیت نداشتم و امروز دوباره برگشتم و امیدوارم هرجا هستید حالتون خوب باشه. در حال حاظر به صورت Full time دارم مطالعه میکنم قطعا پست های جالب تر و عمیق تری نسبت به قبل خواهیم داشت. امروز برای دست گرمی با معرفی یک ابزار شروع میکنیم.

اگر برای سرویستون تست مینویسید و تست های شما وابستگی به دیتابیس داره برای سرعت معمولا سعی میشه که تست ها با یک دیتابیس in-memory اجرا بشه که وابستگی بیرون نداشته باشه و دردسر کمتری هم این روش داره.
حالا مشکلی که اینجا وجود داشت این که اگر پروژه شما به #MongoDB وابستگی داشته باشه در این راه برای استفاده از پکیج مربوط به In memory در حالت هایی دردسر زیادی داره که استفاده از روش های پایین خیلی منطقی تره.

روش هایی که در این حالت میشد استفاده کرد به این صورت بودن:
- استفاده یک دیتابیس جدا و کاملا ایزوله
- استفاده از Service ها در CI/CD pipeline مثل github and gitlab services ( در صورت نبود دیتابیس in memory این روش خیلی بهتری هست )
https://docs.github.com/en/actions/use-cases-and-examples/using-containerized-services/about-service-containers
https://docs.gitlab.com/ee/ci/services/

برای دیتابیس های SQL هم معمولا از #Sqlite نسخه In-memory رو به عنوان engine در هنگام تست استفاده میکنن ولی به این نکته باید توجه داشت که #Sqlite مثل هر #SQL دیگ تفاوت هایی با بقیه دارد و اگر همون تست ها رو بخواید با دیتابیس دیگ مثل #Postgres و #MySQL اجرا کنید ممکنه به خطا بخورید که این هم بخاطر تفاوت ها هست. مخصوصا اگر در تست هاتون به Primary key وابستگی داشته باشید که قطعا خیلی زیاد پیش میاد. ولی درکل هندل کردنشون به طوری که روی همشون کار کنه کار سختی نیست و با ریفکتور کوچیک بیشتر مواقع این موضوع حل میشه.
نمونه کد برای اجرا کردن #Sqlite با #NodeJS پکیج استاندارد جدیدی که اخیرا اضافه شده.

import { DatabaseSync } from 'node:sqlite';
const database = new DatabaseSync(':memory:');

البته شما باید باتوجه به ORM که استفاده میکنید کانفیگ رو انجام بدید.

برای Redis هم که Package مربوط به redis in-memory هست میتونید نصب کنید و استفاده کنید.

و حالا میرسیم برای #MongoDB دردسر ساز که این پکیج کارتون رو راه میندازه. نکته ای که وجود داره این که شما اگر بخواید با استفاده از in memory mongo پروژه خودتون تست کنید اگر هر نسخه از #NodeJS کانتینر برای تست خودتون استفاده کنید کار نمیکنه که جزیاتش رو میتونید داخل داکیومنتش ببینید و البته در این حالت ترجیح میدم از سرویس services مربوط به gitlab یا github استفاده کنم.
https://github.com/typegoose/mongodb-memory-server

خب چند روز پیش این پست رو گذاشتم و گفتم این موضوع یک موضوع خیلی پایه ای مربوط به CS داخلش هست که امکان نداره کتاب درمورد زبان هایی مثل C یا سیستم عامل بخونید و به این کلمه اشاره نشه.
این کلمه هست Endianness حالا سوال پیش میاد ربط این دستان با این عکس چیه.
درمورد داستان سفر های گالیور هست که در دنیا Lilliputian یک مذهبی وجود داشت که تخم مرغ رو باید از قسمت کوچیک ترش بشکنی و به اینا میگن little endian. یکسری هم ظاهرا ساز مخالف که باید تخم مرغ رو از سمت بزرگش بشکنی که میشه big endian و ظاهرا در این سرزمین درگیری های زیادی هم بخاطر این که چطور تخم مرغ رو باید شکست بوده.
حالا چه ربطی به کامپیوتر داره؟
شما این عدد رو در نظر بگیرید که معادل HEX این رو داخل عکس میبینید.
168,496,141 = 0A0B0C0D
در ریاضی دوم دبستان وقتی یکان دهگان صدگان یاد گرفتیم به این درک رسیدیم که سمت چپ ترین عدد بیشترین وزن رو داره که به این صورت میتونیم عدد بالا رو نشون بدیم.

100,000,000 + 60,000,000 + 8,000,000 + 400,000 + 90,000 + 6,000 + 100 + 40 + 1

حالا اگر تبدیل مبنا ها رو بلد باشید اگر دیتا bin رو بخواید تبدیل به decimal کنید میدونید که bit ها هرکدوم وزن دارند. حالا یک بحثی اینجا هست که اگر بخوایم یک دیتایی رو در یک مجموعه متوالی از حافظه بخوایم ذخیره کنیم اون قسمتی که بیشترین وزن رو دارد آیا باید در اولین خونه حافظه قرار بدیم یا در آخرین خونه حافظه مربوط به این بخش.
خب اینجا معماری های مختلف CPU مثل X86, ARM, RISC-V جنگ تخم مرغی خودشون دارن ( دقیق یادم نمیاد کدوم چه شکل هست میتونید خودتون برید سرچ کنید )
بعضیا دوست دارن که اون Byte که بیشترین وزن رو داره در اولین خانه از حافظه ذخیره بشه. این میشه Big endian در عکس هم که میبینید مقدار 0A که دراین سناریو بیشترین وزن رو داره در خانه A که اولین خانه RAM هست در این سناریو ذخیره شده.
بعضیا هم میگن که باید اون Byte که بیشترین وزن رو داره در آخرین خانه از حافظه باید ذخیره بشه و اولین خانه از حافظه باید کمترین وزن رو داشته باشه. این میشه Little endian که در عکس میبینید مقدار 0A در این سناریو در آخرین خانه از حافظه یعنی A+3 ذخیره شده که بیشترین وزن رو داره و در خانه اول یعنی A مقدار 0D ذخیره شده.

#CS