پاول دورف :

من در آستانه ۴۱ سالگی هستم، اما احساس نمی‌کنم که باید جشن بگیرم.

نسل ما در حال از دست دادن زمان برای نجات اینترنت آزادی است که پدرانمان برای ما ساختند.

آنچه زمانی وعده‌ی تبادل آزاد اطلاعات بود، اکنون در حال تبدیل شدن به ابزار نهاییِ کنترل است.

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

آلمان هر کسی را که جرأت کند در اینترنت از مقامات انتقاد کند، تحت تعقیب قرار می‌دهد. بریتانیا هزاران نفر را به خاطر توییت‌هایشان زندانی می‌کند. فرانسه در حال تحقیق کیفری از رهبران فناوری است که از آزادی و حریم خصوصی دفاع می‌کنند.

یک دنیای تاریک و ویران‌شهری با سرعت در حال نزدیک شدن است — در حالی که ما در خوابیم. نسل ما در خطر آن است که در تاریخ به عنوان آخرین نسلی ثبت شود که آزادی داشت — و اجازه داد آن را از او بگیرند.

به ما دروغ گفته شده است.

به ما القا کرده‌اند که بزرگ‌ترین نبرد نسل ما، نابود کردن هر آن چیزی است که نیاکانمان برای ما به جا گذاشتند: سنت، حریم خصوصی، حاکمیت، بازار آزاد، و آزادی بیان.

با خیانت به میراث نیاکانمان، خود را در مسیری به سوی خود‌تخریبی قرار داده‌ایم — از نظر اخلاقی، فکری، اقتصادی، و در نهایت زیستی.

پس نه، من امروز جشن نخواهم گرفت.
زمان من در حال پایان یافتن است.
زمان ما در حال پایان یافتن است.

تا حالا فکر کردین استراتژی redis برای پاک کردن کلیدهای cache که ttl اونها اکسپایر شده چیه؟

در واقع redis دو تا استراتژی داره که از ترکیب این دو برای مدیریت این موضوع استفاده میکنه.

1️- استراتژی اول که بهش میگن lazy expiration ساده ترینشه اینه که وقتی درخواستی برای گرفتن یه کلید اومد اول چک میکنه اون کلید اکسپایر شده یا نه اگه آره اون رو همونجا پاک میکنه و نال برمیگردونه.

2- خب اگه یه کلید برای مدت‌ها صدا زده نشه چی؟ اینجاست که میرسیم به استراتژی دوم یعنی active expiration و به این شکله که میاد مثلا هر 100 میلی ثانیه توی لوپ یه batch که شامل مثلا 20 کلید تصادفی هست رو بررسی میکنه و اونایی که اکسپایر شدن رو پاک میکنه. اگه توی اون لوپ بیشتر از 25 درصد کلیدها پاک بشن اون رو زباله تشخیص میده و حدس میزنه کلیدهای بیشتری هم اکسپایر شدن پس یه batch دیگه اجرا میکنه و در نهایت لوپ تموم میشه تا دوباره لوپ بعدی.

برای همین برخلاف تصور، کلیدهای cache بالافاصله با اتمام ttl حذف نمیشن و ممکنه برای مدتی توی حافظه سرور باقی بمونن مخصوصا اگه حجم کلیدها بالا باشه.

پ.ن: چک کردن تعداد کلیدها در هر لوپ و تعداد اجرای لوپ‌ در ثانیه توی کانفیگ redis قابل تنظیمه، ولی نکته ای که هست هر چی تعداد رو بالاتر ببرین کلیدها سریعتر حذف میشن اما cpu بیشتری درگیر میشه.

@DevTwitter | <Farshad Tofighi/>

ای جان :)
ایشون ناراحته و میگه 2 ماهه داریم سعی می‌کنیم برنامه نویس استخدام کنیم هیچکدومشون برنامه نویس نیستند.
هر تسکی میدیم با AI میزنن و بعدش ازشون میخوایم کد رو توضیح بدن و یا دیباگ کنن ، با کله می‌خورن زمین.
و در آخر تمنا می‌کنه که اگر دیباگ کردن بلد نیستید به خودتون برچسب برنامه نویس بودن رو نزنید وقت ما رو هم نگیرید.

ایشون هم میگه تقریبا هر کسی که می‌شناسم شغلش را از طریق یک دوست یا از طریق یک رئیس/کارمند سابقش پیدا کرده.
و بیشتر مشاغل خوب به هر حال آگهی نمی‌شوند و به واسطه ارتباطات نیرو رو جذب می‌کنند.

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

منطقی هم هست دیگه. شما خودت یه جا نیرو نیاز باشه اول زنگ میزنی به اون رفقایی که میشناسی.در نهایت اگه پیدا نشد ، (که به احتمال بسیار زیاد میشه) میری آگهی ثبت می‌کنی.

حالا بیخیال این حرف های تکراری که تو همه جا هست. بریم یک چیز جدید یاد بگیریم 👇

🔥 اجرای دستورات سرور از دل Node.js

زمانی که توی پروژه‌های Node.js کار می‌کنید، حتماً(حالا نه حتماً ولی شاید) پیش اومده(یا شاید پیش بیاد) که بخواید یه دستور ترمینال (Shell) رو از داخل کدتون اجرا کنید. مثلاً یه اسکریپت پایتون رو ران کنید، با ffmpeg یه ویدیو رو پردازش کنید یا حتی وضعیت یه سرویس رو چک کنید.

درسته که با exec می‌تونیم اینکار رو کنیم ،اما exec یه مشکلی که داره باید صبر کنیم تا دستور کامل تموم بشه.که ما اعصابش رو نداریم.

اینجاست که می‌تونیم از یک ابزار قدرتمندتر به نام spawn از ماژول داخلی child_process بهره مند بشیم!
‏spawn به جای منتظر موندن، یه فرآیند جدید ایجاد می‌کنه و به شما اجازه میده خروجی (و حتی خطاها) رو به صورت زنده و لحظه ای دریافت کنید.

‏فرض کنید می‌خوایم دستور ping google.com رو اجرا کنیم و خروجی رو همون لحظه ببینیم.

import { spawn } from 'child_process';

// دستور اصلی 'ping' و آرگومانش 'google.com'
const process = spawn('ping', ['google.com']);

// 1. گوش دادن به خروجی موفقیت‌آمیز (stdout)
// این قسمت با هر خط جدیدی که در خروجی چاپ بشه، اجرا میشه
process.stdout.on('data', (data) => {
  console.log(`[LOG]: ${data}`);
});

// 2. گوش دادن به خروجی خطا (stderr)
process.stderr.on('data', (data) => {
  console.error(`[ERROR]: ${data}`);
});

// 3. وقتی فرآیند کاملاً تموم شد
process.on('close', (code) => {
  console.log(`✅ فرآیند با کد خروجی ${code} بسته شد.`);
});

#server #nodejs

نکنه دامنه هم مافیا داره؟
یعنی هر اسمی که به ذهنم رسید زدم ، هر اسمی. ولی از قبل گرفته شده بود!
مگه داریم!

مشتی...
اتل متل رو با چه فکری خریدی؟

این روزا به شدت درگیر شدم...
اما به زودی با یک سورپرایز قراره برگردیم😁

اینم از وضعیت
‏.com رو که فعلاً کلا بیخیال شدیم
مافیاش جهانیه 😂

آیا می‌دانستید زبان جاوا در اصل قرار بود Oak باشه (بلوط)، ولی این دامنه گرفته شده بود!
تیم توسعه توی انتخاب دنبال اسم ساده، کوتاه و باحال بودن.
یکی از اعضا قهوه‌ی «Java Coffee» روی میزش بود و گفت جاوا! شد همین.

منم روی میزم رو کلی گشتم ولی چیزی پیدا نکردم که دامنه اش آزاد باشه.
شما روی میزتون چیزی دارید که دامنه اش آزاد باشه؟

چطوری از هیچی، رسیدم به طراحی اوبر؟

یه حقیقت تلخ:
یه روزایی بود هرچی مطلب درباره System Design می‌دیدم، رد می‌کردم.
با خودم می‌گفتم: اینا مال سینیورهاست، مال من نیست.

ولی وقتی تو یه مصاحبه گفتن «یه اوبر طراحی کن!»
خشک شدم…

در حد REST API حرف زدم و دیتابیس MySQL
بعدش سکوت…
نه از مقیاس‌پذیری سر در می‌آوردم، نه از صف، نه حتی لوکیشن لحظه‌ای.

از اون روز تصمیم گرفتم این قضیه هیچ‌وقت دوباره تکرار نشه.

چیکار کردم؟

1️⃣ قبول کردم هیچی نمی‌دونم و طبیعیه
سیستم دیزاین یه مبحث نیست، یه دنیاس:
• چجوری دیتا می‌چرخه
• سرویس‌ها چطور با هم حرف می‌زنن
• چطور سیستم زیر فشار نمی‌پره
یکم‌یکم جلو رفتم، نه دنبال کامل‌گرایی.

2️⃣ کل موضوع رو تیکه‌تیکه یاد گرفتم
از مفاهیم پایه مثل DNS و CDN
تا دیتابیس‌ها، شاردینگ
تا کش و لود بالانسر
تا معماری‌ها مثل میکروسرویس و Event-driven

هرکدوم‌شون یه چراغ روشن کردن تو ذهنم

3️⃣ دیدم آدم‌ها چطور فکر می‌کنن، نه فقط چی میگن
مصاحبه‌های ماک دیدم
اشتباه می‌کردن، برمی‌گشتن، توضیح می‌دادن
اونجا بود فهمیدم سیستم دیزاین یعنی:
• سوال درست بپرس
‏• trade-off توضیح بده‏
• نه جواب حفظی

4️⃣ کشیدم روی کاغذ
طراحی یعنی تصویر، نه حفظ کردن.
یه فلو ساده:
‏Client → Load Balancer → App → DB
همه‌چی یهو معنی پیدا کرد.

5️⃣ با مسائل واقعی تمرین کردم
واتس‌اپ، اینستاگرام، یوتیوب
نیازمندی‌ها، دیتابیس، اسکال، خرابی‌ها
هفته‌ای یه پروژه
نه دنبال جواب درست
دنبال دلیل پشت انتخاب‌ها

6️⃣ تو کار واقعی هم استفاده کردم
صف آوردیم، سرویس‌ها جدا کردیم
سیستم قابل‌اعتمادتر شد
اونجا فهمیدم اینا فقط برای مصاحبه نیست، برای زندگی حرفه‌ایه!

7️⃣ به بقیه یاد دادم
هرچی ساده‌تر توضیح بدی
یعنی واقعا فهمیدی.

حرف آخرم:
سیستم دیزاین جادو نیست.
لازم نیست ۱۰ سال سابقه داشته باشی.
فقط باید شروع کنی:

• از پایه‌ها
• از مثال‌های واقعی
• هفته‌ای یک‌بار تمرین
• پشت هر انتخاب دلیل داشته باش

سه ماه فقط روزی نیم ساعت وقت بذاری
خودت تعجب می‌کنی از پیشرفتت

سیستم دیزاین یعنی طرز فکر
نه تعداد نمودارهایی که حفظی.

از «وقتی URL رو می‌زنیم چی میشه؟» شروع کن
تا طراحی اینستاگرام

قدم‌به‌قدم
سیستم‌به‌سیستم
قوی‌تر میشی 💪

https://medium.com/@himanshusingour7/how-i-learned-system-design-d7444d454367

در رابطه با پست قبلی
این دوره می‌تونه شروع خیلی خوبی باشه👌

قلب آدم به تپش در میاد در این لحظه که نکنه یهو رنگش قرمز بشه

تست نویسی یکی از مهارت ها و واجباتیه که شاید توی خیلی/بعضی از پروژه ها یا شرکت ها مهم پنداشته نشه، و یا نسبت بهش کم لطفی شده باشه.
اما امروز میخوام این موضوع رو بررسی کنیم و بگیم که چرا اگر مهم پنداشته نمیشه ، از این بعد باید بشه.

اول از همه این رو مشخص کنیم که تست ها چی هستند؟
تست ها کد هایی هستند که بررسی میکنند که کد اصلی پروژه درسته یا خیر.
یعنی شما یک کدی برای پروژه نوشتی ، بعد باید تست کنی ببینی که آیا این کد کار می‌کنه به درستی؟
خب یکی از روش های تست کردن کد اینه که مستقیما بیاریمش تو کار و تستش کنیم. مثلا یک کد در React نوشتیم و این کد یک دکمه هست که وقتی روش کلیک کنی باید یک پیامی رو نشون بده.
ما میایم خودمون در لحظه مستقیما کلیک میکنیم و تست میکنیم که اون پیام رو نشون میده یا خیر.
یا مثلا ما یک وب سرور داریم و یک API نوشتیم و می‌خوایم تست کنیم ببینیم که این API به درستی کار می‌کنه؟ نتیجه ای که ما می‌خوایم رو میده؟
اینجا هم یک روشی که هست اینه که میایم و با postman یا امثالهم ، ریکویست میزنیم و به API و چک می‌کنیم که خروجی که ما می‌خوایم رو میده آیا؟ یا خیر.

اما همانطور که می‌بینید همه این مراحل به صورت دستی چک میشه ، و روزی روزگاری اگر کدمون رو تغییر بدیم ، هر بار باید خودمون دستی تست کنیم که ببینیم اون بخش به درستی کار می‌کنه یا خیر.

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

الان در عکس بالا من مجموعا 9 تا تست نوشته بودم ، که 5 تاش شکست خورد. یعنی چی؟ یعنی مثلا اگر 9 تا فانکشن داشته باشم، از این 9 تا 4 تاش اون خروجی که باید بدن رو میدن، ولی 5 تای دیگه اون خروجی که میخوام رو نمیدن و مشکل دارن. و کد باید بازبینی بشه و ایراداتش بر طرف بشه.

خب حالا که فهمیدیم تست چه می‌کنه ، یکم از انواع تست ها بگیم که در ادامه به مزایای اون می‌خوام اشاره کنم.
تست ها انواع مختلفی دارند . چندتا از اون ها رو نام می‌برم :
Unit testing , Integration testing , System testing , Security testing , E2E testing , ...

به طور کلی در وب سرور ها چند نوع تستی که خیلی استفاده میشه و خود من هم از اینها استفاده می‌کنم :
Unit testing , Integration testing , E2E testing

راجع به هر کدوم در پارت های بعدی توضیح میدم.
البته انتظاری نیست خیل مثال هایی که میزنم رو کامل متوجه بشید و ... . من دارم یک سر نخی میدم بیشتر. و تلاشم رو می‌کنم کوتاه و ساده توضیح بدم.

Part 1

#test

‏Unit testing چیست؟
‏unit testing همانطور که از اسمش معلومه ، یعنی تست یک بلاک کوچک از برنامه. که معمولا یک فانکشن یا متد یک کلاس هست.

مثلا ما یک فانکشن داریم که وظیفه اش آپدیت کاربر در دیتابیس هست.
ما میایم مخصوصا فقط این تکه کد رو بررسی می‌کنیم که آیا به درستی کار می‌کنه؟
مثلا این رو ببینید :

updateUser(id: string, data: Partial<User>): Promise<User> {
    return this.usersRepository.update(id, data);
  }

در این کد ما میایم کاربر رو آپدیت می‌کنیم.(به این هم دقت کنید که ما درون این فانکشن، متد update رو از یک کلاس دیگه کال کردیم. در unit testing ما چون هدفمون فقط تست کردن لاجیک فانکشن مورد نظر هست، نمیتونیم اجازه بدیم که این متد کال بشه. چون درون این متد هم احتمالا یک سری فانکشن های دیگه کال میشن و خلاصه وابستگی های خودش رو داره. در نتیجه میایم این متد رو mock می‌کنیم که در جلوتر میگم چیه) حالا اگر بخوایم براش تست بنویسیم چی میشه؟

    test('Should update user and return it', async () => {
      const result = await usersService.updateUser('1', mockUserDto);

      expect(result).toEqual(mockUserEntity);
    });

میشه ایشون.
من اومدم از یک کتابخونه ای با نام jest استفاده کردم که یک سری توابع برای تست کردن کد در اختیارم قرار میده.
توابع test و except از همین کتابخونه هستند.
خب حالا چیکار کردیم؟ اومدیم یک توضیحی راجع به متدی که قراره تست بشه رو توی test نوشتیم ، و بعد فانکشن رو کال کردیم، نتیجه رو گرفتیم و دادیمش به expect و چک کردیم که همون نتیجه ای که ما می‌خوایم است؟ اگر بله که خیلی هم عالی. تست pass میشه. اگر خیر که بازم عالی. تست failed میشه و ما میفهمیم که مشکل از کجاست. شاید تستمون رو بد نوشتیم شاید هم کدمون ایراد داره، در هر صورت مشکل رو بر طرف می‌کنیم.

اما چیزی که خیلی توی چشم میزنه در این کد ها ، این کلمه mock هست.
این mock یعن چی؟

به طور کلی ، ما در unit test ها نمی‌تونیم متد ها و توابع دیگه درون تابعی که می‌خوایم تست کنیم رو کال(اجرا) کنیم. دلیلش هم توی پرانتز بالا گفتم.
ما باید این متد و توابع رو ماک کنیم. ماک کردن یعنی اینکه بیایم توابع و متد های درون تابعی که میخوایم تست کنیم رو قبل از تست مشخص کنیم که خروجی اش چیه. یعنی ما میایم کاری می‌کنیم که این متد update همیشه یک نتیجه ای که ما می‌خوایم رو داشته باشه. مثلا من اومدم این متد رو ماک کردم که همیشه خروجی اش یک user با id و اطلاعات ثابتی که من میخوام باشه ، تا در ادامه تست بتونیم روی چیز های مهم تر مربوط به این فانکشنی که قراره تست بشه بپردازیم.

که البته در این مثالی که زدیم چیز های مهم دیگه ای نداره، و عملا نوشتن unit test روی توابعی شبیه به این توابع بی فایده است. برای این توابع باید Integration tests و یا E2E tests بنویسیم.
‏Unit tests بیشتر در جاهایی به درد میخورن که شرط و شروطی درون اون توابع نوشته شده باشه.

یعنی درون این توابع یک ifی چیزی باشه که بتونیم ورودی های مختلف بدیم و خروجی های مختلف رو چک کنیم.

مثلا به این مثال توجه کنید :

function max(a, b) {
  return b > a ? b : a
}

همونطور که می‌بینید این یک فانکشن هست که ما دو تا ورودی می‌گیریم و چک می‌کنیم که کدوم عدد بزرگتره. هر کدوم که بزرگتر بود رو بر میگردونیم.
به نظر شما چه تست هایی برای این میشه نوشت؟
از نظر من این تست ها رو میشه براش نوشت :
در تست اول دو تا عدد میدم به تابع و انتظار دارم عدد اول رو بر گردونه.
در تست دوم دو تا عدد میدم و انتظار دارم که عدد دوم رو برگردونه.
در تست سوم هر دو رو مساوی میدم و انتظار دارم که یکی از اینها رو برگردونه. تست هاش میشه به این شکل :

  test("should return the first argument if it is greater", () => {
    const a = 2;
    const b = 1;

    const result = max(a, b);
    expect(result).toBe(a);
  });
  test("should return the second argument if it is greater", () => {
    expect(max(2 , 3)).toBe(3)
  });

  test("should return the first argument if the arguments equal", () => {
    expect(max(2 , 2)).toBe(2)
  });

Part2
#test #unit_tests