Node Master

👇 استخدام نیروی سنیور NestJs 👇 👋 باسلام و درود و ارادت 😎 خدمت برنامه نویسان محترم 💎 دوستان 🌦 Nest کاری که میدونن مهارت کافی برای انجام پروژه دارن، لطفا دایرکت رزومه ارسال کنن 📌 لوکیشن: ریموت 🌐 ⚡️ مزایا: در مصاحبه بعد از تایید رزومه 🔗 پیش نیاز ها: ◀️ تسلط به Nest ◀️ تسلط به Sequelize ◀️ تسلط سوکت ◀️ تسلط کافی به ساختار و بنای HTTP ◀️ داشتن و تجربه کار با محیط های پروداکشن، استیجینگ ◀️ دانستن روش های مختلف اتصال و تفکیک کانفیگ های داخلی و خارجی (برنامه و دوآپس) ❗️ طبعا ممکنه هممون برخی از موارد بالا رو ندونیم و یا شرکت با شرکت متفاوت باشه؛ ایرادی نداره! لطفا رزومتون رو بفرستین بدون نگرانی از کمبود اطلاعات. امیدوارم که قبول بشین ✔️💪 👀 آیدی جهت ارسال رزومه: ▶️ @mostafa_effati #Work

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

دوستان که با من کم و بیش درمورد roadmap و یا نظرم رو درمورد مسیرشون پرسیدن همه میدونن من چقدر شخصا روی مبحث database و db design خیلی تاکید زیادی دارم. در این توییت یک کتاب که مدتی هست دارم میخونم معرفی کردم و نکاتی هم کلی گفتم. https://x.com/imanhpr_media/status/1808176854945177927?t=6qvq2I-HaKufcJh4a0KGSQ&s=19 این کتاب خیلی کتاب با ارزشی هست و برا من حکم یک سلاح مخفی داره و خب باعث competitive advantage زیادی برای من شده.

یک خورده دارم #React مرور میکنم برای پروژه شخصی. یک موضوعی که به ذهنم اومد این هست که چطور موقع هندل کردن event ها با handler function ها چطور stack trace تمیزی داشته باشیم. در این پست درمورد این موضوع و این که چطور stack trace تمیزی داشته باشیم با مثال #Express روی #NodeJS صحبت کردیم. https://t.me/NodeMaster/228 در این پست هم راجع به Reflection صحبت اشاره ای کردیم. https://t.me/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

به تازگی نسخه جدید 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

در حال مطالعه داکیومنت 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://t.me/NodeMaster/137

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

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

#Tip #SQL

جا داره تشکر کنم از همه دوستان. چنل 800 نفر شد و گروه هم 300 نفر به تازگی شدیم. دوستان جدید خیلی خوش اومدین❤️ دوستان قدیمی تر مرسی که همراه من بودین تا اینجا❤️. دوستان جدید تر خدمت شما بگم که اگر دوست داشتید ما یک گروه داریم که درمورد مفاهیم برنامه نویسی صحبت میکنیم و خوشحال میشیم کنارمون باشید. @NodeMasterGP و اگر نیاز به کمک و راهنمایی دارید اگر دوست داشتید پیوی من میتونید پیام بدین و واقعا خوشحال میشم اگر بتونم کمکی کنم. @napoleon_n1 و این که از همتون واقعا ممنونم که به من لطف دارین و باعث پیشرفت من شدین❤️ داداش کوچیک شما ایمان هستم👍🔥

یک 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

داشتم طبق عادت stackoverflow میگشتم دنبال نکته جدید برای یادگیری. به یک سوال خوردم و وقتی روش وقت گذاشتم حس کردم یک باگ روی #NodeJS هست و رفتار منطقی نمیبینیم و خب بقیه هم ظاهرا به همین نکته رسیدن اون سوال باعث ایجاد یک issue روی #NodeJS coe شد اگر دوست داشتید نگاهی به سوال بندازید و برسیش کنید خیلی جذاب بود. سوال: https://stackoverflow.com/questions/78630248/how-to-properly-abort-node-readline-promise-question گیت هاب: https://github.com/nodejs/node/issues/53497