چرا بدون انگلیسی، یاد گرفتن برنامه‌نویسی مثل رانندگی با چشم بسته‌ست؟

برنامه‌نویسی فقط کد نوشتن نیست، در واقع نصفش خوندنه!
مستندات، ارورها، آموزش‌ها، فروم‌ها (مثل Stack Overflow) — همه به انگلیسی‌ان.

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

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

پس اگه دنبال رشد واقعی تو برنامه‌نویسی‌ای، حتما روی زبان انگلیسی هم وقت بذار.

استفاده از Array.at()

از ES2022 به بعد، جاوااسکریپت یه متد جدید به آرایه‌ها اضافه کرده به اسم .at()
که دسترسی به المنت‌ها رو خیلی راحت‌تر و خواناتر می‌کنه.


مثال:

const numbers = [10, 20, 30, 40];

console.log(numbers.at(0));  // 10
console.log(numbers.at(-1)); // 40

چرا بهتره؟
• دیگه لازم نیست بنویسی
array[array.length - 1]
• از ایندکس منفی پشتیبانی می‌کنه
• کد کوتاه‌تر و خواناتر میشه

نکته:
at() هم توی آرایه‌ها کار می‌کنه هم روی استرینگ‌ها:

"Hello".at(-1); // "o"

امروز در یکی از مصاحبه‌ های فنی، سوال جالبی ازم پرسیده شد:

💬 «Tailwindcss دقیقا چطور استایل‌ ها رو مدیریت میکنه؟
یعنی برای هر کلاس مثل p-1, p-2 فایل CSS جدا می‌ سازه؟
پس حجم فایل باید خیلی زیاد بشه، نه؟»

🟢 در جواب باید گفت:
Tailwind از JIT Compiler استفاده میکنه. یعنی فقط همون کلاس‌ هایی که در پروژه استفاده میکنی، در خروجی نهایی CSS ساخته میشن.
در نتیجه فایل خروجی معمولا فقط چند ده کیلو بایته.

همچنین مصاحبه گر سوالی در مورد تفاوت بین ورژن 3 و 4 پرسید:
💬 «در ورژن ۴، آیا دیگه نمیتونیم tailwind.config.js داشته باشیم؟»

🟢 باید گفت که میشه.
در Tailwind 4، فایل config اختیاری شده، نه اینکه حذف‌ شده باشه.
اگه فقط بخوای از تنظیمات پیشفرض استفاده کنی، نیازی بهش نداری،
ولی اگه بخوای theme یا plugin های خودت رو تعریف کنی، هنوزم کاملا پشتیبانی میشه.

حتی یه قدم جلوتر رفت و گفت:
💬 «فرض کن میخوای config رو از سمت سرور بگیری، اون وقت چی؟»

🟢 در جوابش، Tailwind ذاتا runtime-config نداره،
اما میشه با CSS Variables یا تولید فایل config در زمان build از سرور، این رفتار رو شبیه‌ سازی کرد.

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

گفتم با شما هم به اشتراک بذارم. امیدوارم مفید بوده باشه.

Matin Taherzadeh

یه مخزن جذاب تو گیت‌هاب هست که بهت یاد می‌ده چطور فقط با CSS بدون نیاز به جاوااسکریپت، کلی کار خفن مثل انیمیشن و منو درست کنی!

برای کسایی که دنبال سایت‌های سبک و سریع هستن عالیه.

اگر دوست داری کدهات ساده‌تر و بهینه‌تر باشن، حتما یه سر بهش بزن!

لینکش

https://github.com/you-dont-need/You-Dont-Need-JavaScript

Farhad Safari

ا SDUI یعنی چی؟

ا SDUI مخفف Server-Driven UI هست، یعنی رابط کاربری هدایت‌شده از سمت سرور.
به زبان ساده:
به‌جای اینکه UI رو کامل توی اپ یا فرانت‌اند بنویسیم، سرور تصمیم می‌گیره که چه UIی باید نشون داده بشه و اون رو به صورت ساختاریافته (مثلاً JSON) برای کلاینت می‌فرسته.

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

یه مثال خیلی ساده

فرض کنین یه API داریم که اینو برمی‌گردونه:

{
  "type": "screen",
  "title": "Login",
  "components": [
    { "type": "text", "value": "Welcome!" },
    { "type": "input", "placeholder": "Username" },
    { "type": "input", "placeholder": "Password", "secure": true },
    { "type": "button", "label": "Login", "action": "/api/login" }
  ]
}

کلاینت فقط این JSON رو می‌گیره و طبق type و components، صفحه‌ی لاگین رو داینامیک می‌سازه.
اگه فردا بخوایم یه دکمه‌ی جدید اضافه کنیم یا متن رو عوض کنیم، فقط کافیه API رو تغییر بدیم.

کجاها استفاده می‌شه؟
۱- اپلیکیشن‌های موبایل (iOS / Android):
چون آپدیت‌دادن برای هر تغییر UI خیلی زمان‌بره، SDUI اجازه می‌ده بدون انتشار نسخه‌ی جدید، UI رو آپدیت کنیم.

۲- سیستم‌های A/B Testing یا personalization:
می‌تونیم برای کاربرهای مختلف، UI متفاوت بفرستیم بدون اینکه چند تا نسخه بسازیم.

۳- پلتفرم‌های multi-brand یا white-label:
مثلاً یه اپ داریم برای چند برند مختلف (با تم و کامپوننت‌های متفاوت)، SDUI خیلی کمک می‌کنه که از یه base code استفاده کنیم.

۴- اپ‌های با تغییر سریع در محتوا:
مثلا marketplaceها، اپ‌های خبری یا فروشگاه‌ها که مدام صفحه‌ها و کمپین‌هاشون عوض می‌شه. (دیوار از همین روش استفاده می‌کنه)

مزایا

✅ بدون انتشار اپ جدید می‌تونیم UI رو تغییر بدیم
✅ انعطاف‌پذیری بالا برای تست و شخصی‌سازی
✅ مناسب برای اپ‌هایی با محتوای زیاد و متغیر

معایب

❌ پیچیدگی زیاد در طراحی رندرر سمت کلاینت
❌ دیباگ و تست سخت‌تر (چون UI از سروره)
❌ در پروژه‌های کوچیک، بیش از حد سنگینه


یه نکته مهم

خیلی از شرکت‌های بزرگ مثل Airbnb, Netflix, Shopify و Uber از SDUI استفاده می‌کنن،
ولی معمولاً فقط برای بخش‌هایی از UI نه کل اپ، چون ترکیبش با UI محلی (Local UI) بهتر جواب می‌ده.

حرکت جالب Stackoverflow

- اگه از ChatGPT و ... استفاده می‌کنین ولی دلتون پیش Stackoverflow هست، می‌تونین از سرویس جدید این شرکت استفاده کنین که شباهت زیادی به چت‌بات های امروزی داره ولی جواب‌هایی به سبک Stackoverflow میده:

https://stackoverflow.ai

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

Bardia

تبدیل nestjs به موشک سرعت

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

مورد اول:
تبدیل http adapter از پیشفرض express به فستیفای
باعث افزایش ۲ الی ۵ برابری سرعت توی درخواست های rest api میشه
مورد دوم:
اضافه کردن کشینگ ردیس توی اینترسپتور ها، باعث میشه سرعت جواب دادن سرویس ها بیشتر بشه و response time خیلی کمتر بشه
مورد سوم:
فشرده سازی درخواست ها، باعث میشه ۱۰ تا ۲۰ درصد سرعت افزایش پیدا کنه، اگر فستیفای آداپتر استفاده میکنید از پکیج
@fastify/compress
میتونید استفاده کنید و اگر اکسپرس استفاده میکنید از پکیج
compress
میتونید استفاده کنید.
مورد چهارم: استفاده از پکیج cluster برای استفاده از هسته های مختلف سی پی یو
import cluster from 'cluster';
import { cpus } from 'os';

if (cluster.isPrimary) {
  cpus().forEach(() => cluster.fork());
} else {
  // bootstrap Nest app
}
اگه سی پی یو چند هسته ای باشه موازی سازی پردازش باعث افزایش سرعت خیلی چشم گیری میشه
مورد پنجم:
این یکی برای توسعس، استفاده از swc به عنوان بیلدر و کامپایلر به جای tsc پیشفرض باعث افزایش ۱۰ تا ۲۰ برابری سرعت توسعه میشه. swc کامپایلر بر پایه rust هستش

Amir Zalaghi

مفهوم abstraction یعنی چی؟

ا Abstraction یعنی پنهان کردن جزئیات غیرضروری و فقط نشان دادن چیزهای مهم.
یعنی وقتی با یه چیز کار می‌کنیم، فقط اون بخش‌هایی رو ببینیم که برای استفاده لازمن، نه اون‌هایی که برای پیاده‌سازی لازم بودن.

در کدنویسی، Abstraction یعنی اینکه ما:
بخش‌هایی از کد رو طوری طراحی می‌کنیم که فقط رفتارهای لازم رو expose کنن؛
ولی جزئیات درونی (پیاده‌سازی) رو پنهان کنن.

مثال:

class UserService {
  private users = [];

  addUser(name: string) {
    this.users.push(name);
  }

  getAllUsers() {
    return [...this.users];
  }
}

اینجا:
بیرون از کلاس فقط addUser و getAllUsers در دسترس هستن.
کسی نمی‌دونه (و نباید بدونه) که users چطور ذخیره می‌شن، آیا در حافظه‌ان یا در دیتابیس.

خب فایدش چیه؟
وابستگی بین قسمت‌های مختلف برنامه کم میشه
می‌تونیم راحت‌تر کد رو تغییر بدیم یا تست کنیم
شلوغی‌ها تا جای ممکن کم میشه

جاوااسکریپت یا تایپ‌اسکریپت؟ کِی از کدوم استفاده کنیم؟

یکی از سؤال‌های رایج بین برنامه‌نویس‌ها اینه که آیا باید پروژه رو با جاوااسکریپت شروع کنیم یا تایپ‌اسکریپت؟
پاسخ کوتاه اینه: بستگی به نوع پروژه و هدفت داره.


زمانی که جاوااسکریپت انتخاب بهتریه:
• پروژه کوچکه و نیاز به ساختار پیچیده نداره
• می‌خوای سریع نمونه اولیه (prototype) بسازی
• اعضای تیم هنوز با TypeScript آشنا نیستن
• قصد داری فقط سمت مرورگر (Frontend) کار سبک انجام بدی

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


زمانی که باید سراغ TypeScript بری:
• پروژه بزرگ یا بلندمدته
• تیم چندنفره داری و می‌خوای از اشتباهات زمان اجرا جلوگیری کنی
• نیاز به type safety و autocomplete قوی داری
• ساختار کدها باید قابل نگهداری و قابل توسعه باشه

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


جمع‌بندی:
اگر هدفت سرعت و سادگیه، جاوااسکریپت انتخاب خوبیه.
اما اگر پایداری، مقیاس‌پذیری و خوانایی کد برات مهمه، TypeScript انتخاب منطقی‌تره.

در واقع، یادگیری هر دو ضروریه. جاوااسکریپت پایه است، TypeScript نسخه‌ی امن‌تر و حرفه‌ای‌تر اون.

موافقید؟

بازنویسی کامپایلر TypeScript با Go

شرکت Microsoft اعلام کرده که در حال مهاجرت (port) یا بازنویسی کامپایلر TypeScript از جاوااسکریپت به زبان Go هستند.
هدف اصلی؟ بهبود چشمگیر عملکرد، کاهش زمان کامپایل و مصرف حافظه.


نکات کلیدی:
• کامپایلر فعلی TypeScript (tsc) تا امروز عمدتاً در جاوااسکریپت/TypeScript اجرا می‌شده؛ حالا پروژه‌ای تحت عنوان «native port» راه افتاده که کد در Go اجرا خواهد شد.
• بنچمارک‌های اولیه نشان میدن که سرعت کامپایل روی پروژه‌های بزرگ ممکنه ۱۰ برابر سریع‌تر بشه.
• این تغییر تأثیری بر نحوه‌ی استفاده برنامه‌نویس‌ها از TypeScript نداره؛ syntax و APIها ثابت می‌مونن. فقط پشتِ‌صحنه اجرا بهینه‌تر میشه.



چرا Go؟
چند دلیل مهم پشت انتخاب Go:
• پشتیبانی قدرتمند از هم‌زمانی (concurrency) که برای پردازش فایل‌های زیاد و تحلیل AST کامپایلر مهمه.
• جمع‌آوری خودکار حافظه (garbage collection) و ساختار داده‌ها که می‌تواند برای برنامه‌ای به پیچیدگی یک کامپایلر مناسب‌تر باشه.
• امکان پورت «تابع به تابع» (functionally similar) از کد قدیمی به کد جدید بدون بازنویسی کامل.



چه چیزی تغییر می‌کند؟
برای شما به عنوان توسعه‌دهنده‌ی TypeScript، تغییر عمده‌ای نیست.
کدی که تا حالا نوشتی همون کدی هست که خواهی نوشت.
ولی زمان ساخت پروژه‌ها، زمان پاسخگویی ابزارها و مصرف حافظه در پروژه‌های بزرگ بهتر خواهد شد.

پکیج: dotenv-expand
احتمالاً با dotenv آشنا هستین، پکیجی که متغیرهای محیطی رو از فایل .env لود می‌کنه.
اما اگه بخوایم توی .env از یه متغیر داخل متغیر دیگه استفاده کنیم، dotenv به‌صورت پیش‌فرض اینو ساپورت نمی‌کنه.

اینجا می‌تونیم از dotenv-expand استفاده کنیم.

APP_NAME=My-Project
APP_PATH=/var/www/${APP_NAME}

اینجا از APP_NAME تونستیم توی یک متغیر دیگه هم استفاده کنیم. فقط توی کد باید کد زیر رو اضافه کنیم:

import dotenv from "dotenv";
import dotenvExpand from "dotenv-expand";

const env = dotenv.config();
dotenvExpand.expand(env);

console.log(process.env.APP_PATH); // /var/www/My-Project

تمیزی و نظم فایل .env رو زیاد می‌کنه و جلوی تکرار بی مورد رو می‌گیره.
برای پروژه‌های چندمحیطی (dev, staging, prod) عالیه.
نیاز به تغییر در dotenv اصلی نداره.

بک اند یاد بگیرم یا نه ؟

روی صحبتم با کسایی هست که چندسالی تجربه موفق توی فرانت اند داشتن :

خیلی ها اعتقاد دارن باید یه مهارت رو یاد گرفت و توی همون عمیق شد و تا تهش رفت , تا حدی درسته اما دنیای وب خیلی گستردس خصوصا برای کسی که عاشقه کدنوشتن هستش و برنامه نویسی رو فقط به چشم یه شغل نگاه نمیکنه

به نظر من وقتی فرانت بلدی یاد گیری بک اند واست هم راحت تر میشه و هم دیده بهتری بهت میده خصوصا اگر زبان عوض نکنی و یه چیزی مثل node ,express یادبگیری

اگر فرانت‌اند کار هستی، یه روزی وقت بذار و سمت سرور رو هم کشف کن, قول می‌دم طرز نگاهت به کد برای همیشه تغییر کنه.

وقتی یادگیری بک‌اند رو شروع کردم، فکر می‌کردم فقط قراره با دیتابیس و API سروکار داشته باشم.
ولی چیزی که واقعاً یاد گرفتم، تفکر سیستمی بود.
حالا وقتی کد فرانت‌اند می‌نویسم، بهتر می‌فهمم درخواست‌ها از کجا میان، چرا باید بهینه باشن، و چطور یه تصمیم ساده توی UI می‌تونه روی Performance سرور تأثیر بذاره.
یادگیری بک‌اند برای من فقط یه مهارت جدید نبود؛ یه زاویه دید تازه بود به دنیای برنامه‌نویسی.

Kamyar Kamazani