سلام و ارادت دوستان.
نکته امروز رو با یک سوال شروع میکنیم. بنظرتون چرا باید از Object.freeze بیشتر استفاده کنیم؟

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/freeze

نسخه 20.11 LTS برای #NodeJS منتشر شد.
- بهینه سازی های خیلی زیاد در fs module اتفاق افتاده.
- اضافه کردن معادل __dirname و __filename که در CJS وجود داشت در ماژول های ESM

import.meta.dirname // ESM
__dirname //CJS

import.meta.filename // ESM
__filename //CJS

قدیما برای بدست اوردن filename و dirname باید با استفاده از import.meta.url اینکار میکردی که زیاد جالب نبود.
به عنوان مثال معادل import.meta.dirname قبل از این ورژن این شکل بود.

import path from "node:path";
import url from "node:url";

const __dirname = path.dirname(url.fileURLToPath(import.meta.url)); // Before 20.11 LTS
// import.meta.dirname 20.11 LTS
const __filename = url.fileURLToPath(import.meta.url); // Before 20.11 LTS
// import.meta.filename 20.11 LTS

console.log(__filename);
console.log(__dirname);

#NodeJS
#Update

این شاید یک static method کوچیک باشه ولی فلسفه پشتش نیاز به توضیح زیادی داره. به این مثال توجه کنید.

const channel = Object.freeze({ name: "NodeMaster" });
channel.name = "IDK"; // TypeError

خیلی ساده هست با کمک Object.freeze من object مورد نظر رو به readonly تبدیل میکنم و شما نمیتونید این رو عوض کنید. ساده بنظر میاد اما اصلا چرا به همچین چیزی نیاز داریم؟ در کل اکوسیستم این رفتار رو به شکل ها و سطوح مختلف میبینید که پایین چنتا مثال زدم.

- در زبان #RustLang تمامی variable ها به صورت پیشفرض immutable هستند و شما باید به صراحت اعلام کنید که یک variable mutable هست.
- یکی از اصول زبان های functional تاکید بر immutable بودن object ها دارد.
- یک best practise وجود داره که میگه همیشه از const استفاده کنید مگر واقعا نیاز داشته باشید که این کار رو نکنید.

پشت تمامی این داستان ها میرسیم به یک جمله معروف که میگه "mutability is evil". تمام نکات بالا برمیگرده به همین جمله معروف اما سوال پیش میاد که چرا برای این موضوع اینقدر پیچدگی داریم؟ اصلا چرا؟
جواب این هست که immutable بودن object ها به ما کمک میکند تا side effect ها را به حداقل برسونیم. این نکته به این معنی نیست که side effect ها چیز بدی هست. نکته این هست که بدون side effect کلا نوشتن برنامه مفید غیرممکنه ولی اگر کمترش کنیم بهمون میتونه کمک کنه. حالا چنتا سوال خیلی مهم پیش میاد برامون.

- داستان side effect چی هست و چرا باید کمترش کنیم؟
- داستان immutable و mutable چیست؟
- چطور کمتر کردن side effect بهمون کمک میکنه؟
- کجاها side effect میتونه فاجعه بار باشه؟
- ربط mutability با side effect چیه؟

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

#Tip

امروز در گروه کانال بچه ها راجع به concurrency در #NodeJS یکم صحبت کردن من هم از این فرصت استفاده میکنم توضیحاتی بدم.
این جمله رو زیاد شنیدیم #NodeJS به صورت Single thread و async هست. این جمله یک نقص بزرگ داره و آدم رو به اشتباه میندازه. کامل تر این شکل میشه که بخش آخر رو بگیم #NodeJS در حقیقت Async I/O است. این I/O خیلی مهم هست. در برنامه نویسی هر task به دو دسته تقسیم میشه که میشه به چشم bottleneck نگاه کرد
- کار های I/O base (Input/Output) : منظور از این مدل کار ها گرفتن یا فرستادن اطلاعات به کلاینت مثل فرستادن http request دریافت http response یا همون network یا کار با file system و ...
- کار های CPU Intensive ( به صورت عادی باعث بلاک شدن event loop و یا کند شدن میشوند. ) : تبدیل فرمت عکس از jpg به png یا پرداش ویدیو یا tls termintion یا فرایند فشرده سازی http response تولید شده با استفاده از gzip. حتی for loop ساده !
ما concurrency مدل های مختلفی داریم که مثال
- Async IO
- multithreading
- multiprocessing
برای کار های از نوع IO بهترین مدل asyic i/o هست برای کار های cpu intesive دو مدل دیگ. مدل hybrid و ترکیبی اینها هم وجود داره که خیلی پیشرفته هستن و زیاد هم استفاده میشن. نمونه خیلی معروف مدل Hybrid که انقلاب بود و هست Nginx.
در بهترین حالت این هست که ما با #NodeJS کار CPU intensive انجام ندیم اما گاهی مجبوریم. حالا با استفاده از "node:child_process" و "node:worker_thread" میتونیم کمک خیلی زیادی به Node کنیم.
در مثال پایین با یک کار فیک CPU intensive به طور کل event loop رو بلاک میکنیم و بعد با worker thread برنامه رو سریع تر میکنیم. اول با تعریف یک کار cpu intensive شروع میکنیم

function cpuBlockingTask() {
    for (let i = 0; i < 5e5; ++i) console.log(i);
  }

کد خیلی ساده هست با for تا 500.000 هزار میشماریم لاگ میگیریم. این به این معنی هست هربار در برنامه node خودتون دارید loop میزنید در حقیقت دارید به Node خیانت میکنین. به هیچ عنوان روی آرایه های بزرگ از متد های foreach, map ,every و ... استفاده نکنید.
بعد با http ماژول یک وب سرور ساده مینویسیم

import http from "node:http";

function cpuBlockingTask() {
  for (let i = 0; i < 5e5; ++i) console.log(i);
}
http
  .createServer((req, res) => {
    cpuBlockingTask(); // Block event loop
    res.end("Done"); // Send response after loop
  })
  .listen(3000, () => console.log("Server is listning on port", 3000));

روی پورت 3000 یک وب سرور داریم که بعد از انجام دادن کار cpuBlockingTask یک 200 با متن Done میفرسته. سرور رو ران کنید.
یک ابزار هست به اسم AutoCannon برای Load test های ساده استفاده میشه. حجم زیادی از ریکوست رو میفرستیم سمت سرور.
https://www.npmjs.com/package/autocannon
توپ رو شلیک میکنیم سمت سرور با حالت پیشفرض که داخل داکیومنت نوشته البته یک flag هم ست میکنیم تا درخواست های موفق رو بشماریم.

autocannon --renderStatusCodes localhost:3000

نتیجه در سیستم من‌ : فقط ۳ ریکوست موفق با تنظیمات پیشفرض

بخش اول ❇️
ادامه پست بعدی ❇️

حالا با worker thread به Node کمک میکنیم.

import http from "node:http";
import { fileURLToPath } from "node:url";
import { Worker, isMainThread, parentPort } from "node:worker_threads";

const __filename = fileURLToPath(import.meta.url);

if (isMainThread) {
  // This code will run by main thread
  http
    .createServer((req, res) => {
      const worker = new Worker(__filename, { stdout: true });
      worker.on("exit", () => {
        res.end("Done");
      });
      worker.postMessage(null);
    })
    .listen(3000, () => console.log("Server is listning on port", 3000));
} else {
  // This code will run by workers
  function cpuBlockingTask() {
    for (let i = 0; i < 5e5; ++i) console.log(i);
  }

  parentPort.on("message", () => {
    cpuBlockingTask(); // Run Blocking Task on worker thread
    process.exit(); // exit worker thread after task
  });
}

خیلی وارد جزیات نمیشم اول با isMainThread تشخیص میدیم آیا داخل main thread برنامه هستیم یا خیر. در thread اصلی وب سرور رو run میکنیم و کار های سخت رو میدیم به worker ها که در else block هست. نکته جذاب اینجا هست که ارتباط بین thread ها با استفاده به یک چیزی شبیه به چنل ها در #GoLang هست. برای هر ریکوستی که به سمت سرور میاد یک worker ایجاد میکنیم و وقتی کارش تموم شد done رو میفرستیم سمت کلاینت. چون thread ها با message ها مختلف با هم صحبت میکنن ما با worker.postMessage میگیم که کارمون رو انجام بده. بعد شما وقتی process.exit در worker thread انجام میدی اون thread خارج میشه و برنامه اصلی کار میکنه و اینطور میتونیم به thread اصلی بگیم که من کارم تموم شد response رو بفرست. خیلی وارد جزیات فلن نمیشیم و برنامه رو اجرا میکنیم با کامند بالا با استفاده از AutoCannon
نتیجه در سیستم من‌ : ۶۰ ریکوست موفق با تنظیمات پیشفرض.

همینطور که میبینید با کدی که خیلی خوب نیست 20 برابر در این مثال ساده تونستیم pref رو ببریم بالاتر. حالا نکاتی که باید در نظر بگرید درمورد کد.
- این کد اصلا خوب نیست به دلیل این که در scale زیاد اگر برای هر ریکوست یک native thread باز کنیم نه تنها باعث سریع تر شدن نمیشه بلکه از یک حدی برنامه شروع به خزیدن روی زمین میکنه.
- به صورت کلی concurrency در برنامه نویسی یک تخصص سخت هست یعنی شما میتونی اینقدر عمیق بشی در این مبحث که با noscript شغلی Concurrency Expert یا Concurrency Specialist داشته باشی.
- برای concurrency هم یک سری دیزاین پترن خیلی مهم وجود داره مثل worker pool که میتونید راجع بهشون بخونید و این ادامه نکته دوم هست.

2 روز پیش نسخه 21.6 #NodeJS منتشر شد. واقعا سرعت آپدیت #NodeJS خیلی بالا هست. از مهم ترین ویژگی هایی که اضاف شده به این نسخه.
- به permission system یک flag جدید اضافه شده که در صورت import کردن native module ها باید به صورت explicit اجازه بدین.

node --experimental-permission --allow-addons

- حالا در این نسخه فلگ --allow-fs-* به راحتی میتونید از relative path استفاده کنید.

node --experimental-permission --allow-fs-read=./index.js

- یک فلگ جدید اضافه شده به اسم --build-snapshot-config. این flag کمکی هست برای build-snapshot. این flag خیلی پر استفاده برای برنامه های روزمره نیست ولی خب در آینده درمورد این flag صحبت خواهیم کرد.

https://nodejs.org/en/blog/release/v21.6.0

امروز درمورد Duck Typing صحبت میکنیم. این موضوع مربوط به رفتار زبان های dynamic type میباشد. البته این تکنیک در زبان هایی static type هم در حالت های خاصی استفاده میشود. برای درک این موضوع با مثال در #Python شروع میکنیم.

class Duck:
    def fly(self):
        print("quak quak !")

class Airplane:
    def fly(self):
        print("boom boom !")

#Duck Test
def fly_test(vehicle):
    vehicle.fly()

flyable = [Duck() , Airplane()]
for f in flyable:
    fly_test(f)

یک جمله خیلی معروف و کلیدی در این مورد وجود داره که باتوجه به اون مثال بالا رو توضیح میدیم."if it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck."
به این معنی هست "اگر شبیه به اردک شنا میکنه کواک میکنه پس احتملا اردک هست."
در زبان های dynamic type مفهومی به اسم interface نداریم و اگر یک class یک method رو تغریف کرده باشه شما بدون نیاز به type میتونید اون method رو به راحتی call کنید. الان در کد بالا هیچ نشانه ای از type نیست و فانکشن fly_test بدون داشتن دانشی از این که ایا arg ورودی fly method دارد یا خیر این متد رو call میکنه. به این کار میگن duck testing. در کل بگم به هیچ عنوان fly_test براش مهم نیست vehicle چی هست فقط براش مهم هست که fly وجود داشته باشد.
حالا سوال پیش میاد که اگر این متد نبود چی؟ الان در این مثال اگر اگر متد fly نباشه روی یکی از این کلاس ها خب runtime error داریم و برنامه crash میکنه. دو دیدگاه برای جلوگیری از این مدل runtime error ها داریم که در پست بعدی برسی میکنیم هردو رو.
نکته جالب دیگه این هست که Airplane و Duck این دو کلاس هیچ رابطه ای با هم ندارند و صرفا فقط به صورت قراردادی هردو یک fly method رو implement کردن. در #TypeScript از Duck Testing زیاد استفاده میشه برای داشتن کد TypeSafe در حقیقت تکنیک Type Predict به نوعی Duck Test میتونه محسوب بشه.

این مقدمه ای برای این بحث بود. در حقیقت برای داشتن همچین مدل رفتاری مدل های فکری مختلفی در زبان های مختلف هست. در زبان #Java ما از inerface ها و abstract class ها استفاده میکنیم در #GoLang شما یک نوع دیگه از Duck Typing رو میبینید که بهش میگن Structural Typing و interface های golang بهمون کمک میکنن در #TypeScript هم Structural Typing به شدت مرسوم هست و مثال خواهیم زد، در پایتون که Duck Typing رو دیدید ولی نکته جالب اینجا هست که Structural Typing و abstract class ها هم در پایتون خیلی بهمون کمک میکنن ولی خب کمتر کسی از وجود این ها خبر داره.
این نکته هم بگم که هیچ کدوم از این راه حل ها نسبت به دیگری برتری خاصی ندارند صرفا نوع تفکره بیشتر البته البته زبان های Static و TypeSafe میتونن develop رو راحت تر کنن در این مورد. این که کدوم تکنیک در کدوم زبان استفاده میشه مهم هست چون که به عنوان مثال Duck Typing در java خیلی مرسوم نیست و استفاده ازش سخت تره اما در یک حالت های خاصی خیلی میتونه در این زبان کمک کنه.
#Tip

این پست رو لینکدین گذاشتم.
درمورد مقدس نبودن clean code و design patterns ها نکاتی گفتم.
شاید بدردتون بخوره

https://www.linkedin.com/posts/imanhpr_clean-code-horrible-performance-activity-7155431493845069824-TSsf?utm_source=share&utm_medium=member_android

دوستان جدیدتر راستی برای چنل یک گروه داریم درمورد مفاهیم برنامه نویسی و پرسش پاسخ هست دوست داشتید خوشحال میشیم جوین بشید.
@nodemastergp

قبلا درمورد Type Predict ها در #TypeScript صحبت کردیم از این لینک یک مطالعه کنید

https://news.1rj.ru/str/NodeMaster/90

و این که یک قسمت گفتیم که دو دیدگاه برای فیکس کردن همچین crash هایی در Runtime وجود دارد.

- Easier to ask for forgiveness than permission (EAFP)
- Look before you leap (LBYL)
قبل از این که درمورد این دو دیدگاه صحبت کنیم باید بگم که هرکدوم از این ها در یک زبان هایی مرسوم هست. به عنوان مثال در #Python نماد کد تمیز استفاده از EAFP و در #Javanoscript باید از LBYL استفاده کرد.
خودتون یکم برید راجع به این دوتا مطالعه کنید و بنظرتون بگید که Type Predict ها در #TypeScript از کدوم از این استایل ها استفاده میکنن؟

اینجا هم یک نمونه از Duck Typing قبلا در یکی از پست ها گفته بودم که به عنوان سوال بود.
https://news.1rj.ru/str/NodeMaster/118

یک ابزار جدید از سمت مایکروسافت برای #TypeScript معرفی شده به اسم TypeSpec.
کارای زیادی میتونه کنه.
خودم چیز زیادی ازش نمیدونم ولی یک نگاهی شما هم دوست داشتید بندازید.
https://typespec.io/

#Weekly

#Work

https://www.linkedin.com/posts/amir-honarmand-zade_aepaebaesaewaexaepaet-nodejs-aetaecaevaex-activity-7153837711496261632-gH3G?utm_source=share&utm_medium=member_android

تشکر از بچه های گروه که این کار رو معرفی کردن.

دوستان اگر دوست داشتید به گروه اینجا جوین بشید.

@nodemasterGp

برای درک مفهوم Duck Test و کلا Duck Typing میتونیم با این مثال درمورد Promise ها نکاتی یاد بگیریم. فرض کنید فانکشنی داریم که یک Promise رو میگیره و حالا یک کاری انجام میده.

function doWork(promise) {
  promise.then(() => {
    console.log("Work Is Done");
  });
}

const newPromise = Promise.resolve("Hello Promise");
doWork(newPromise);

مثال خیلی ساده هست. به این نکته توجه کنید که ما اینجا هیچ نوع type check نداریم. و برنامه میتونه در runtime به مشکل بخوره اگر workPromise یک instance از Promise نباشد. توجه کنید ما همین الان هم داریم از Duck Typing استفاده میکنیم چون در doWork هیچ خبری نداریم و فقط then رو call میکنیم با فرض این که Promise یا Duck باشد.
حالا کد رو یکم بهتر میکنیم.

import { types } from "node:util";

function doWork(promise) {
  if (types.isPromise(promise)) {
    promise.then(() => {
      console.log("Work Is Done");
    });
  }
}

در "node:util" یک namespace داریم به اسم type که در اینجا یک سری فانکشن کمکی برای چک کردن تایپ ها ( Type predict function ) داریم که به ما کمک میکنن که کد safe تر باشه. الان این کد رو اگر اجرا کنید همه چیز اوکی هست و کار میکنه. ولی یک edge case اینجا وجود داره که خیلی کمتر به چشم میاد. با مثال بعد متوجه میشید ولی بزارید اول با یک سوال مطرح کنم موضوع رو.
اگر Promise Object ما از Native Promise خود #Javanoscript نباشد چه اتفاقی پیش میاد؟ قطعا این کد به مشکل میخوره چون isPromise فقط Native Promise ها رو چک میکنه و نه 3rd party ها که ممکنه در خیلی از code base ها باشه.
به عنوان مثال اگر از پکیج زیر استفاده شده باشه.
https://www.npmjs.com/package/promise
حالا اگر فقط این پکیج import شده باشه این کد به مشکل میخوره

import Promise from "promise";

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

import Promise from "promise";
import { types } from "node:util";

function doWork(promise) {
  if (types.isPromise(promise) || promise instanceof Promise) {
    promise.then(() => {
      console.log("Work Is Done");
    });
  }
}

دوباره اینجا یک مشکل پیش میاد چون فقط همین یک پکیج نیست. به عنوان مثال اگر bluebird استفاده کرده باشن کد مشکل میخوره. خب منظورم رو تا الان متوجه شدین بریم سراغ Duck Test. اون جمله معروف که در پست اول گفتیم رو به یاد بیارید اول و حالا دقت کنید.
درسته این پکیج ها متفاوت هستند ولی همشون interface های یکسانی دارند. اینجا دوست دارم یک رفرنس بزنم به یک جمله معروف که اگر عمیق درکش کنید چند level یک شبه در برنامه نویسی پیشرفت میکنید.
"program to interfaces, not implementations"
اینجا دقیقا این lib ها از این مفهوم استفاده کردند برای Promise به ما implementation های زیادی داریم ولی نقطه مشترک همشون داشتن interface یکسان هست که به عنوان مثال همشون متد .then دارند. اصن وقتی در مثال بالا ما بدون تغییر کد فقط با import کردن کل ساختار رو عوض کردیم که کد به مشکل خورد مثال همین موضوع هست.
حالا کافیه با استناد به این جمله کلیدی و زیبا و Duck Test و فرض گرفتن که همه این lib ها متد .then رو دارند شرط رو عوض کنیم.

function doWork(promise) {
  if (promise && promise.then && typeof promise.then === "function") {
    promise.then(() => {
      console.log("Work Is Done");
    });
  }
}

حالا شما اگر شرط بالا رو به این صورت بنویسید (دقیقا مثل type predict ها در #TypeScript) میبینید که کد با هر library کار میکنه. چون شما وابستگی خودتون رو از implementation شکوندین و به interface وابسته شدین. مهم نیست که object ورودی یک instance از Promise خاصی باشد. مهم این هست که شبیه به Promise ها رفتار کند ( به عنوان مثال متد .then داشته باشد).

این بود مفهوم Duck Test به صورت کاربردی. توجه کنید که کد بالا به صورت production ready نیست و صرفا فقط برای توضیح مفاهیم بود.
امیدوارم خوشتون اومده باشه.

#Tip
#NodeJS

اگر تمام این مفاهیم که تا الان باهم یاد گرفتیم رو بخواهیم بندازیم دور و فقط و فقط یکیش رو یاد بگیریم. همین جمله معروف
"program to interfaces, not implementations"
میتونید درموردش داخل این stack overflow بیشتر یاد بگیرید.

https://stackoverflow.com/questions/2697783/what-does-program-to-interfaces-not-implementations-mean

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

من یک تشکر از دوستان کنم.
گروه چنل 100 نفره شد🎉.
از همه ممنونم امیدوارم گروه و چنل براتون مفید باشه❤️

یکی از مشکلاتی که در #NodeJS وجود داره Manage کردن ورژن های مختلف Package manager ها هست. همونطور که میدونید پکیج منیجر های مختلفی برای #NodeJS وجود داره که در پایین میبینید.
npm - bun - yarn - pnpm
حالا باتوجه به سلیقه شخصی هرشخصی در پروژه های خودشون از این پکیج منیجر ها استفاده میکنند. جدا از این ممکنه یک پروژه ای از یک ویژگی مربوط به یکی از اینها استفاده کنه که وابستگی زیادی بین پروژه و پکیج منیجر ایجاد میکنه.
فرض کنید یک پروژه رو میخواید به سیستم دوستتون انتقال بدید که از pnpm استفاده میکنه دوستتون yarn داره اینجا دوتا چالش به وجود میاد.
- چالش نصب pnpm به صورت دستی
- نصب ورژن مورد نیاز پروژه
حالا در همچین سناریو هایی #NodeJS در ورژن های v16.9.0, v14.19.0 ابزاری به اسم corepack اضافه کرده که بهتون کمک میکنه اعضای تیم خودتون رو سریعتر به مرحله productive بودن روی پروژه های جدید برسونید. وقتی nodejs رو نصب میکنید corepack به صورت پیش فرض نصب هست ولی به دلیل experimental بودن غیرفعال هست. برای فعال کردنش میتونید از command زیر استفاده کنید

corepack enable

بعد حالا اگر میخواید مثلا مشخص کنید که پروژه شما از pnpm نسخه 8 استفاده میکنه که در هنگام انقال همه چی فیکس باشه میتونید از این command استفاده کنید.

corepack use pnpm@8.x

بعد از این کامند به package.json شما یک attr اضافه میشه شبیه به زیر که ورژن دقیق package manager شما رو مشخص میکنه.

{
"packageManager": "pnpm@8.15.1+sha256.245fe901f8e7fa8782d7f17d32b6a83995e2ae03984cb5b62b8949bfdc27c7b5"
}

حالا اگر روی یک سیستم دیگ شما برای نصب package manager برای این پروژه از command زیر استفاده کنید تمام مشکلات بالا حل میشه و دقیقا package manager مناسب پروژه خواهید داشت

corepack install

این ابزار میتونه برای تیم هایی که با #NodeJS کار میکنند کمک خوبی باشه که دست خط های خودشون رو یکی کنند.

نظر شخصی : به تازگی روی یکی از پروژه ها محل کارم از این موضوع استفاده کردیم و در نگاه اول بازخورد خوبی داشتیم.

#Tip

مدتی هست در خبرنامه های #NodeWeekly خبر خاصی به چشمم نمیاد واقعا.
این هفته خبر اومدن نسخه 5.4 Typenoscript به صورت Beta رو دیدم.
https://devblogs.microsoft.com/typenoscript/announcing-typenoscript-5-4-beta/

و نسخه 6 برای فریم ورک AdonisJS که حرکت بزرگی زدن و به صورت پیش فرض اومدن روی ESM
https://adonisjs.com/blog/adonisjs-v6-announcement

سلام دوستان ارادت. همونطور که اطلاع دارید یک گروه داریم به اسم @NodeMasterGP که دور هم جمع شدیم تا بتونیم باهم پیشرفت کنیم.
اعضای گروه چند شب پیش داشتن درمورد موضوعی صحبت میکردن که در نهایت یکی از دوستان تصمیم گرفت یک وبینار رایگان برگزار کنه برامون.
مدرس این وبینار آقای رستم دخت سابقه خیلی زیادی در زمینه BackEnd دارن.
تاریخ برگزاری وبینار از ساعت 19:30 تا 22:30 روز چهار شنبه 18 بهمن ماه هست که میتونید شرکت کنید.

از این لینک میتونید ثبت نام کنید.
https://formafzar.com/form/f21m6

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

منبع :
https://blog.sonatype.com/npm-flooded-with-748-packages-that-store-movies

#Security