طبق عادت همیشگی داشتم پروژه Node روی گیتهاب چک میکردم و آخرین کامیت که ۳ ساعت پیش خورده خیلی جالب بود برام.
اینطور که شاهده کم کم باید شاهد اومدن http3 روی std برای #NodeJS باشیم باتوجه به این commit که دارن پروتکل quic رو جلو میبرن!

https://github.com/nodejs/node/commit/fc102f2180dfc8e1654ce672185f5bf97ec21b53

#Update

ممنون میشم این پست رو که داخل لینکدین منتشر کردم like و share کنید دیده بشه
https://www.linkedin.com/posts/imanhpr_quic-further-implementation-details-nodejs-activity-7139858976979996672-Fy_S?utm_source=share&utm_medium=member_desktop

این هفته #NodeWeekly خبر خیلی خاصی نبود.
یک ابزار خوب معرفی شد برای cron job ها که میتونه بدردتون بخوره
https://croner.56k.guru/

یکی از نکاتی که میتونه ما رو برنامه نویس بهتری کنه اینه که از اکوسیستم های دیگه هم خبر داشته باشیم و صرفا در حباب stack خودمون نمونیم. حتی در حد بیسیک هم خوبه نیاز نیست چنتا تکنولوژی رو استاد باشید.
در بلاگ رسمی #golang یک پست خیلی با ارزش منتشر شده از Survey رسمی خودشون روی اکوسیستم #golang
خیلی طولانی و کامل هست.
بنظرم نگاهی بندازید من خودم هم اگر نکته ای دیدم اینجا میگم.
https://go.dev/blog/survey2023-h2-results

#استخدام برنامه نویس

Senior Backend NodeJs

تجربه حداقل ۳ سال در توسعه و پیاده‌سازی برنامه‌های وب با استفاده از Node.js
تسلط کامل بر مفاهیم اساسی JavaScript و فریم‌ورک Express.js
تجربه در طراحی و پیاده‌سازی API‌ها با استفاده از RESTful یا GraphQL
تجربه در کار با پایگاه‌های داده مانند MongoDB یا MySQL

شرایط شغلی
حضوری - شنبه تا چهارشنبه ساعت 9 الی 17
موقعیت مکانی شرکت
تهران خ شیراز جنوبی
حقوق؛ توافقی - باتوجه به میزان توانایی
و تجربه
@fatemekia_1375
#Work

اینجا میتونید رزومه خودتون رو بفرستید.

https://jobinja.ir/companies/smartmirror/jobs/C8Pc?_gl=1*1c0pfjk*_ga*MTYwMTQ4MjAwLjE3MDIxMDMwMjg.*_ga_T8HC2S1534*MTcwMjQ4MjM1OC4yNi4xLjE3MDI0ODIzNzMuNDUuMC4w

تفاوت Symbolic reference و Direct reference توی JVM

داشتم یه مطالعه‌ای راجب اینکه JVM چطور کار میکنه میکردم، که دیدم توی یه یه قسمتی از کار JVM میاد Symbolic reference هارو به Direct reference تبدیل میکنه (توی Class Loader > Linking > Resolution این اتفاق میوفته). که باعث شد یکم رفتم خوندم ببینم تفاوت‌شون چیه.

داستان از این قراره، Symbolic reference در واقع یک String هست که میشه باهاش هر field، method یا class ای رو uniquely پیدا کرد باهاش. تشکیل شده از اسم، دیسکریپتور اون field، method یا class.
وقتی JVM داره Byte code رو execute میکنه و به یک Symbolic reference برخورد میکنه (اینطور تصور کنین که شما یک پکیجی نصب کردین روی اپ‌تون و دارید یکی از method هاشو import میکنین توی class خودتون و ازش استفاده میکنین) JVM میره اون field، method یا class رو پیدا میکنه (اگر نیاز باشه Loadش میکنه) و به جای اون Symbolic reference یک Direct reference میزاره. حالا این Direct reference چیه؟ آدرس یا پوینتر اون field، method یا class توی مموری! به همین سادگی‌:))

سری بعدی که JVM به همون Symbolic reference بخوره، دیگه این فرایند رو تکرار نمیکنه، از همون Direct refernceای که قبلاً پیدا کرده بود استفاده میکنه.

اگر میخواین کل فرایند اینکه JVM چطور کار میکنه رو بخونین این پست خیلی خوب توضیح داده.
https://www.freecodecamp.org/news/jvm-tutorial-java-virtual-machine-architecture-explained-for-beginners/

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

class BuggyCls {
  #age;
  set age(value) {
    this.#age = value;
  }

  get age() {
    return this.#age;
  }

  sum2() {
    return this.#age + 2;
  }
}

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

نکته : مربوط به یکی از مباحثی هست که من قبلا اینجا اشاره ای کرده بودم

#Think #Tip

بزارید قبل از توضیح باگ اول راجع به #age توضیح بدم.
وقتی شما در یک کلاس قبل از هر attribute اگر # بزارید اون تبدیل به private میشه. این نوع private کردن با استفاده از کلمه private در typenoscript متفاوت هست.
شما وقتی با # یک فیلد رو private کنید در حقیقت خود انجین تضمین میکنه private بودن رو ولی در typenoscript صرفا فقط یک syntax در زمان compile و قبل از transpile میباشد. بزارید با مثال توضیح بدم.

class Simple {
  private age = 24;
}

const obj = new Simple();

console.log("age" in obj);

خط سوم با استفاده از in ما چک میکنیم که آیا obj یک attr با نام age دارد یا خیر. اگر زبانی مثل جاوا بود قطعا جواب false بود ولی اینجا true برمیگردونه. شما حتی میتونید type cast کنید و مستقیم دسترسی به age داشته باشید!
ولی اگر خط بالا رو با #age بنویسید جواب false میگیرید که منطقی هست چون خود js engine این تضمین رو بهمون میده که private هست ( حالا که چطور این تضمین رو بهمون میده خودش یک بحث طولانی دیگ هست که اینجا مورد نظر ما نیست)

حالا سوال پیش میاد از کدوم استفاده کنیم برای private کردن فیلد ها؟
جواب خیلی بستگی داره و باتوجه به تحقیقی که من کردم خیلی دو دستگی و سلیقه ای هست این بخش. البته در آینده قطعا آدما بیشتری سمت این ویژگی خواند رفت و چون این داخل ES2022 اضافه شده و خیلی جدیده کلا طول میکیشه تا همه استفاده کنن چون که ویژگی جدیده هست و داخل آموزش ها معمولا نمیگن.

نکته بعدی این که وقتی داشتم سوال بالا رو طراحی میکردم قصد داشتم یک باگ خیلی معروف رو برسی کنیم ولی بیشتر که رو سوال دقت کردم رسیدم به جمله معروف "javanoscript is garbage" چون اون سوال حتی من که طراحیش کردم یک باگی داشت که خودم دوباره بهش دقت نکرده بودم. البته برمیگرده به ساختار و فلسفه زبان که بنظرم فرصت خیلی خوبی هست عمیق تر بشیم
#Tip

NodeMaster.ir
Coming Soon!

همکاری در پوزیشن توسعه دهنده بک اند
ما یک‌شرکت فناور مستقر در پارک علم و فناوری دانشگاه تهران و بازوی فناوری هلدینگ معدنی سنگ آهن هستیم. ما به دنبال یک همکار توسعه دهنده در پوزیشن بک اند با استک nest هستیم و توانایی های مورد انتطارمون:
تسلط بر typenoscript و فریمورک nest
توانایی کار با git
توانایی تست نویسی
توانایی داکیومنتیشن
توانایی کار گروهی و حل مساله
حقوق و دستمزد را به صورت توافقی و بر  اساس نوع همکاری تعیین میکنیم.
ضمنا محصول یک وب اپلیکیشن تخصصی در زمینه هوشمندسازی معادن است.
Naghshtech@gmail.com
@Ali_ramez

#Work

رشته پست مربوطه :‌ https://news.1rj.ru/str/NodeMaster/81

خب بریم سراغ باگی که قرار بود راجع بهش صحبت کنیم. بزارید یکم راجع تاریخچه باحال این باگ صحبت کنیم.
Null References: The Billion Dollar Mistake
اولین بار این null رو در زبان ALGOL در سال 1965 درست کرد فقط به دلیل این که پیاده سازیش خیلی راحت بود براش. کلا درمورد null ها همیشه همه جا بحث زیاده و به این دلیل بهش میگن billion doller mistake که یهویی داخل runtime یچیزی میبینی که نباید و برنامه کرش میکنه. مقالات زیادی راجع بهش هست که میتونید مطالعه عمیق تری داشته باشید راجع بهش و یک تایم دیگه خود این موضوع رو عمیق تر صحبت میکنیم.
توضیح باگ‌: شما اگر قبل از set کردن مقدار age با استفاده از setter متد sum2 رو invoke کنید به دلیل این که مقدار #age تعریف نشده و undefined (یا همون null‌) هست و وقتی یک عدد رو با undefined جمع کنید مقدار NaN رو میگیرید که همین خودش یک موضوع دیگس.
بزارید اول این رو بگم که یکی از دلایلی که میگن "js is garbage" همین Billion Dollar Mistake به دلیل این که نه تنها یک مقدار بلکه دو مقدار برای نشان دادن null داریم یعنی خود null و undefined و هرچی راجع به جک این موضوع صحبت کنیم واقعا کمه!
این باگ رو شما اگر از #typenoscript استفاده کنید در زمان compile میتونید جلوگیری کنید به دلیل این که ts اگر strictnullcheck در ts فعال باشه شما رو مجبور میکنه که این رو درنظر بگیرید.

class BuggyCls {
  #age?: number;
  set age(value) {
    this.#age = value;
  }

  get age() {
    return this.#age;
  }

  sum2() {
    if (this.#age === undefined || this.#age === null) {
      return this.#age + 2;
    }
    throw new TypeError("Please set a number value for age");
  }
}

شما در خط دوم به ts میگید که این مقدار میتواند undifiend هم باشد و در متد sum شما رو مجبور میکنه که از guard استفاده کنید تا کدتون رو امن کنید. به این موضوع میگن null safety. یک روش دیگ هم برای تعریف فیلدی که میتواند null هم باشد هست که من معمولا از اون روش استفاده میکنم.

#age: number | null = null;

هر دو روش تفاوتی در نهایت ندارن و سلیقه هست من به این دلیل از این استفاده میکنم چون خیلی explicit تر هست و معمولا میگن از undifiend مستقیم استفاده نکنید و برای جاهایی بزاریدش که خود js engine اون رو برمیگردونه.
این موضوع هم البته صرفا یک practise هست و شما باید در نهایت استایل خودتون رو داشته باشید.

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

#Tip

در پست قبلی راجع به اصل باگ توضیحاتی دادیم ولی رسیدم سروقت این که چرا ما NaN میگیریم. بزارید با یک مثال در #python و #javanoscript رو کنار هم بزاریم و اونجا میتونیم بهتر متوجه بشیم.

>>> 2 + "text"
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'int' and 'str'

> 2 + "text"
'2text'

این دو خط خیلی شبیه به هم هستند هردو یک مقدار string رو با یک مقدار integer جمع کردیم ولی جواب نهایی خیلی متفاوت هست. دقیقا همین رفتار باعث میشه که زبان ها رو به دو دسته تقسیم کنیم
- weakly typed
- strong type
قبل از این که توضیح بدم راجع به این دو این رو در نظر بگیرد که #python یک زبان strong type و #javanoscript یک زبان weak type هست و حالا با دونستن این فکت میتونیم توضیحات رو کامل تر کنیم.
به عنوان مثل در زبان های strong type اگر دو expresion از type های مختلف بخواد پردازشی روشون انجام بشه خود compiler یا interpreter جلوگیری میکنه از این کار مثل کد پایتون بالا که به صراحت میگه هردو باید یک type باشند و فرایند این تبدیل باید به صورت explicit توسط برنامه نویس انجام شود ولی در زبان های weakly type نتیجه میشه تکه کد js که این به نوعی خیلی میتونه ترسناک باشه! حالا اگر بخوایم نتیجه شبیه به کد js داشته باشیم منظور از explicit بودن در مثال پایین میبینید.

>>> str(2) + "text"
'2text

اینجا میبینید که برنامه نویس از فانکشن str برای تبدیل integer به string به صراحت ( explicitly ) استفاده کرده و منظور از explicit بودن این هست.
تفاوت زبان های strong و weak type به همینجا خطم نمیشه و ساعت ها میشه راجع بهش صحبت کرد ولی خب در همین حد فعلا کافی هست چون موضوعات دیگه ای هم هست که باید اشاره کنیم.

بزارید من اینجا یکبار دیگ تاکید کنم که "زبان های Weakly type میتوانند خیلی ترسناک باشند." بزارید این رو یکم بازتر کنم براتون با مثال

> null + 2
2
> undefined + 2
NaN

>>> None + 2
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'NoneType' and 'int'

داخل سوالی که بالا طرح کرده بودم دقیقا امکان داشت این اتفاق تک کد بالا پیش بیاد که مقدار undefined با 2 جمع بشه و اینجا javanoscript هیچ اروری به شما نمیده و برنامه روند عادی خودش رو طی میکنه و خدا فقط میدونه کی و کجا یک validation از این جلوگیری کنه. حتی امکان داره ماه ها این باگ ها داخل کدتون بمونه و شما خبر نداشته باشید و از اون بدتر امکان ایجاد record های خراب داخل database هم هست. نکته جالب اینجا بود که وقتی integer رو با null جمع کردم و عدد 2 رو گرفتم خودم سوپرایز شدم. کلا weakly type ها همیشه میتونن شما رو سوپرایز کنن.
ولی خب به عنوان مثال در زبان strong type به صراحت interperter گیر میده و حتی ممکنه برنامه crash کنه.

این نکته خیلی مهم رو توجه کنید که این به معنی بد بودن weakly type lang ها یا خوب بودن strong type lang ها نیست هرکدوم مزایا و معایب خودشون رو دارن و این ما هستیم که باید از اینها درست استفاده کنیم. فقط باید این رو درنظر بگیرید که در زبان ها weakly type باید خیلی خیلی دقت بیشتری کنیم.

نظر شخصی :‌
- در اینجور مواقع من ترجیح میدم برنامه crash کنه تا در سکوت به کار خودش ادامه بده چون crash کردن خیلی خسارت کمتری وارد میکنه تا دیتای خراب روی دیتابیس

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

فکر میکردین پشت پرده یک NaN گرفتن اینقدر داستان باشه؟ کامنت کنید😂
#Tip

مرسی از همه شما واقعا باورم نمیشه ۳۰۰ نفر شدیم❤️🎉
امیدوارم مطالب مفید باشه براتون واقعا انگیزم بیشتر شد

اگر در NodeJS برای وب سرورتون Auth service مینویسید و اگر فرایند Auth شما بر پایه password باشد. معمولا به این صورت مقایسه پسورد صورت میگیرید.

if (hashed_pass_from_db === hashed_pass_from_input) {
  console.log("sucess")
}

این تکه کد یک مشکل امنیتی خطرناک داره که به چشم نمیاد به راحتی. این مشکل هم دقیقا بخاطر استفاده از "===" هست.
حالا این مشکل چیه و چطور رفعش کنیم. به این باگ امنیتی میگن Timing attack.
اینطور کار میکنه که با استفاده brute force هربار یک پسورد رو سمت back-end ارسال میکنند و با استفاده از زمان response حدس میزنند که چندرصد این پسورد درسته و اینقدر این کار میکنن تا پسورد درست رو بدست بیارن.
اگر از کتابخونه های bcrypt استفاده میکنید معمولا به روش امن براتون پسورد رو چک میکنند اما اگر از scrypt که قبلا توضیح دادم استفاده میکنید شما باید از یک function کمکی در ماژول crypto استفاده کنید.

crypto.timingSafeEqual(Buffer.from("a"), Buffer.from("a"))

این فانکشن زمان مقایسه رو constant میکنه. یعنی زمان مقایسه پسورد اشتباه با درست همیشه یکی هست و اینطوری attacker نمیتونه حدس بزنه. بدون این موضوع شخص attacker یکم تلاش کنه با تفاضل بین پسورد ها به راحتی به پسورد میرسه.

این ویدیو خیلی قشنگ این مشکل امنیتی رو توضیح میده و خودش براتون با مثال یک timing attack هم انجام میده ‌( ویدیو به زبان پایتون هست ولی حتما ببینید )
https://www.youtube.com/watch?v=XThL0LP3RjY

یکی از قابلیت های خیلی خوب #typenoscript که خیلی کم استفاده میشه "type predicate" هست. به این شکل هست که شما در runtime میتونید یک interface رو valid کنید. همونطور که میدونید interface ها در typenoscript کلا در کد transpile نمیشوند و معمولا اکثرا با استفاده از type cast میان یک object رو تبدیل میکنن به interface. بزارید مثال بزنم.

interface IUser {
  name: string;
  age: number;
}

function main() {
  // data will come in runtime from result of an api call.
  const data: any = { username: 'imanhpr' };
  const castedData: IUser = data; // Warning
}

اینجا یک interface داریم که attr هاش مشخصه ولی همینطوری که میبینید castedData قرار هست یک object باشه که اون interface رو داشته باشه ولی خب در حقیقت data از یک جنس دیگس و تایپ اسکریپت اینجور مسایل رو نمیتون پیدا کنه و ما باید
بهش کمک کنیم.
نیاز به یک چیزی داریم که در runtime بتونه صدرصد به من اطمینان بده که type درستی در اون object هست. اینجاس که "type predicate" میاد به نجات ما.

function isUser(input: unknown): input is IUser

معمولا یک فانکشن هست که یک ورودی با تایپ نامشخص رو میگیره و تبدیل میکنه به یک class یا interface یا type و convention هم این هست که با is شروع میشن مثل isProduct , isAdmin و ... .
حالا چطور ما در runtime ثابت کنیم که input ما کاملا interface رو implemet کرده.

function isUser(input: unknown): input is IUser {
  return (
    typeof input === 'object' &&
    'name' in input &&
    'age' in input &&
    typeof input.age === 'number' &&
    typeof input.name === 'string'
  );
}

با استفاده از کمک کلمات کلیدی typeof و in در #javanoscript. با استفاده از typeof مشخص میکنیم که تایپ یک object چی هست به عنوان مثال وقتی input تایپش unknown هست یعنی ما هیچی نمیدونیم ازش پس اول میایم میگیم اگر object بود ادامه.
بعد با کمک in چک میکنیم که اون attr ها وجود داشته باشند و بعد دوباره با typeof تایپ اون attr ها رو چک میکنیم که درست باشند.
در حقیقت اینجا به صورت خیلی imperative شکل و ظاهر interface رو دارید replicate میکنید در runtime. در حقیقت دوتاشون یک کار میکنن ولی در جاهای مختلف. یکیشون در runtime و اون یکی در compile time. این نکته در زبان ها دیگ یکم متفاوت هست یعنی
جاوا یا golang یکم متفاوت هست.

حالا اگر همه این ها رو جمع کنیم کد کامل به این شکل میشه

interface IUser {
  name: string;
  age: number;
}

function isUser(input: unknown): input is IUser {
  return (
    typeof input === 'object' &&
    'name' in input &&
    'age' in input &&
    typeof input.age === 'number' &&
    typeof input.name === 'string'
  );
}

function main() {
  // data will come in runtime from result of an api call.
  const data: any = { username: 'imanhpr' };
  if (isUser(data)) {
    // logic
  }
  throw new TypeError('Invalid user');
}

نکته اینجا هست که شما type narrowing هم در if block میگرید و میتونید استفاده کنید و صدرصد به شما safety هم در compile time و هم در runtime میده و مجبورین اون case که اگر این interface هم نبود هندل کنید.

#Tip