CodeVerse | دنیای برنامه نویسان

🔥 یه باگ که اولش فکر می‌کردم تقصیر کدمه!

یه بار توی یکی از پروژه‌ها یه درخواست API داشتم که بعضی وقت‌ها درست جواب می‌داد و بعضی وقت‌ها نه.

اولین حدسم این بود که مشکل از کده.

شروع کردم به تغییر دادن Query، بررسی شرط‌ها و حتی چند قسمت از منطق برنامه رو بازنویسی کردم.

ولی مشکل همچنان بود.

آخرش متوجه شدم مشکل اصلاً از منطق برنامه نبود؛
رفتار درخواست‌ها و زمان‌بندی اجرای چند عملیات باعث ایجاد Race Condition شده بود.

اونجا یه چیز مهم برام جا افتاد:

هر باگی که می‌بینی، الزاماً از همون جایی که ظاهر میشه به وجود نیومده.

از اون به بعد موقع دیباگ، فقط به خطی که Error داده نگاه نمی‌کنم؛
کل مسیر اتفاق رو بررسی می‌کنم.

📢 @CodeVerse_dev

🚀 آیا Index بیشتر همیشه یعنی Performance بهتر؟

نه!

خیلی‌ها تصور می‌کنند هرچه روی جدول Index بیشتری داشته باشیم، Queryها سریع‌تر اجرا می‌شوند.

اما هر Index یک هزینه هم دارد.

هنگام اجرای:

INSERT

و

UPDATE

دیتابیس باید Indexهای مربوطه را هم به‌روزرسانی کند.

یعنی:

سرعت خواندن ↑

اما:

هزینه نوشتن ↑

از طرفی Indexهای غیرضروری می‌توانند:

🔹 فضای بیشتری مصرف کنند
🔹 عملیات Write را کندتر کنند
🔹 هزینه نگهداری بیشتری داشته باشند
🔹 انتخاب Execution Plan را پیچیده‌تر کنند

پس Index را فقط بر اساس حدس اضافه نکنید.

اول:

EXPLAIN

بعد بررسی کنید:

Selectivity → Query Pattern → Execution Plan → Actual Performance

یک Index خوب، Indexی نیست که فقط وجود داشته باشد؛

بلکه Indexی است که با الگوی واقعی Queryهای سیستم هماهنگ باشد.

💡 گاهی حذف یک Index اضافی، بیشتر از اضافه کردن یک Index جدید به Performance کمک می‌کند.


@CodeVerse_dev

🔐قابلیت Rate Limiting فقط برای جلوگیری از حمله نیست

خیلی‌ها Rate Limit را فقط یک قابلیت امنیتی می‌بینند.

اما در APIهای واقعی، Rate Limiting بخشی از Resource Management است.

فرض کنید یک Endpoint دارید:

POST /api/send-code

اگر محدودیتی وجود نداشته باشد، یک Client می‌تواند هزاران Request ارسال کند.

نتیجه؟

❌ فشار روی Application
❌ افزایش مصرف Database
❌ مصرف منابع سرویس SMS
❌ افزایش هزینه
❌ احتمال سوءاستفاده

حالا Rate Limit می‌تواند بر اساس موارد مختلف اعمال شود:

IP → User → API Key → Endpoint

اما یک نکته مهم:

این Rate Limit را فقط در Application تعریف نکنید.

در معماری‌های توزیع‌شده، باید مکانیزمی داشته باشید که بین چند Instance هماهنگ باشد؛ مثلاً یک Store مشترک مانند Redis.

امنیت خوب فقط جلوی مهاجم را نمی‌گیرد؛
از منابع سیستم هم محافظت می‌کند.

@CodeVerse_dev

🧠 چرا OFFSET برای Pagination در دیتابیس همیشه انتخاب خوبی نیست؟

در پروژه‌های کوچک این Query کاملاً طبیعی است:

SELECT * FROM posts ORDER BY id DESC LIMIT 20 OFFSET 100000

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

Cursor-based Pagination
مثلاً به جای:
OFFSET 100000
می‌توان گفت:
WHERE id < last_seen_id
و سپس:
ORDER BY id DESC LIMIT 20

مزیت؟

⚡ مناسب برای Feedهای بزرگ
⚡ همچنین Performance پایدارتر
⚡ کاهش اسکن غیرضروری رکوردها

البته انتخاب بین Offset و Cursor به Use Case بستگی دارد؛ Cursor برای همه سناریوها جایگزین مستقیم Offset نیست.
قبل از انتخاب Pagination، به حجم داده و Query Plan فکر کنید.


@CodeVerse_dev

هزارتایی شدیم! 🥳

به تک‌تک شما که این مسیر را با ما همراه شدید، افتخار می‌کنیم. عدد ۱۰۰۰ فقط یک رقم نیست؛ یعنی هزار نفر اعتماد، هزار نگاه و هزار انگیزه برای بهتر بودن.

از صمیم قلب ممنونیم. قرار نیست متوقف شویم، تازه اول راه است! ❤️

با ما بمانید.

📸 افزونه کروم GoFullPage؛ از کل صفحه سایت اسکرین‌شات بگیر!

تا حالا خواستی از یک صفحه وب که خیلی طولانیه، یک اسکرین‌شات کامل بگیری؟
با GoFullPage دیگه لازم نیست چندین بار اسکرین‌شات بگیری و بعد به هم بچسبونیشون! 😎

فقط افزونه رو اجرا کن و خودش صفحه رو از بالا تا پایین Capture می‌کنه.

🔥 چه کارهایی می‌تونه بکنه؟

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

💡 مخصوصاً وقتی می‌خوای طراحی یک سایت رو برای بررسی، ارائه به مشتری یا آرشیو ذخیره کنی، GoFullPage واقعاً کاربردیه.

📌 یه کلیک کل صفحه ذخیره میشه! 🚀

@CodeVerse_dev

وقتی میگن تو که همش پشت میزی چه خستگی داری😞

چرا ()map با ()forEach فرق داره؟ 🤔

خیلی‌ها این دوتا رو تقریباً یکی می‌دونن، در حالی که یک تفاوت مهم دارن که توی کدنویسی واقعی خیلی مهمه.

فرض کن یه آرایه داریم:

const prices = [100, 200, 300];

با ()forEach می‌تونیم روی هر آیتم کاری انجام بدیم:

prices.forEach(price => {
  console.log(price * 2);
});

اما ()forEach چیزی برنمی‌گردونه:

const result = prices.forEach(price => price * 2);

console.log(result);
// undefined

اینجاست که ()map وارد میشه:

const result = prices.map(price => price * 2);

console.log(result);
// [200, 400, 600]

یعنی ()map روی هر آیتم یک عملیات انجام میده و یک آرایه جدید برمی‌گردونه.

پس خیلی ساده:

forEach() → برای اجرای یک عملیات روی آیتم‌ها

map() → برای تبدیل آیتم‌ها و ساختن یک آرایه جدید

مثلاً وقتی از API یه لیست کاربر می‌گیری:

const names = users.map(user => user.name);

اینجا دقیقاً داری از ()map برای استخراج و تبدیل داده استفاده می‌کنی. 🔥

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

اسم متد مهم نیست؛ مهم اینه بدونی هرکدوم برای چه کاری ساخته شده.

@CodeVerse_dev

ابزار مدیریت دیتابیس برای دولوپرهای حرفه‌ای - معرفی TablePlus

یکی از ابزارهایی که هر دولوپری باید داشته باشه، یه مدیریت‌کننده خوب برای دیتابیس هست. TablePlus یکی از بهترین‌ها در این حوزه محسوب میشه.

✅ ویژگی‌های TablePlus:

· پشتیبانی از MySQL، PostgreSQL، SQLite، Redis و MongoDB
· رابط کاربری زیبا و سریع
· امکان اجرای کوئری‌های پیچیده با Auto-complete
· بکاپ‌گیری و ریستور سریع
· نمایش گرافیکی روابط بین جدول‌ها
· نسخه رایگان برای استفاده شخصی

✅ نصب و استفاده:

برای macOS

brew install --cask tableplus

برای ویندوز

از سایت رسمی دانلود کن

💡 ویژگی فوق‌العاده: می‌تونی چندین دیتابیس مختلف رو همزمان باز کنی و بینشون جابه‌جا بشی. همچنین کوئری‌های محبوب رو توی Saved Queries ذخیره کن تا دیگه دوباره ننویسیشون.

⚠️ نکته مهم: همیشه قبل از اجرای کوئری‌های DELETE یا UPDATE، از دیتابیس بکاپ بگیر. TablePlus این قابلیت رو به‌صورت یک‌کلیکی داره.

@CodeVerse_dev

🌐 چرا بعضی لینک‌ها وقتی روشون کلیک می‌کنی، صفحه قبلی رو هم تحت تأثیر قرار میدن؟

این کد رو ببین:

<a href="https://example.com" target="_blank">
    Open
</a>

یعنی لینک داخل Tab جدید باز بشه.

اما یک نکته امنیتی مهم وجود داره.

صفحه مقصد در بعضی سناریوها می‌تونه به صفحه بازکننده از طریق window.opener دسترسی داشته باشه.

برای همین در لینک‌هایی که به سایت خارجی باز میشن، استفاده از:

<a
    href="https://example.com"
    target="_blank"
    rel="noopener"
>
    Open
</a>

انتخاب مطمئن‌تریه.

جالب اینجاست که خیلی‌ها این موضوع رو فقط یک جزئیات HTML می‌بینن.

ولی همین جزئیات کوچیک وقتی داخل یک سایت بزرگ، سیستم تبلیغات، پنل کاربری یا صفحات Third-party استفاده بشن، اهمیت بیشتری پیدا می‌کنن.

نکته مهم‌تر؟

اگر از target="_blank" استفاده می‌کنی، امنیت لینک رو هم به عنوان بخشی از تصمیم در نظر بگیر، نه صرفاً رفتار ظاهری اون.

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

💬 چندتا Attribute HTML می‌شناسی که کاربرد امنیتی هم داشته باشن؟

@CodeVerse_dev

🛠 قبل از نصب افزونه جدید وردپرس، این یک سؤال رو از خودت بپرس

فرض کن برای یک سایت وردپرسی مشتری، فقط یک قابلیت کوچیک لازم داری.

مثلاً:

«وقتی کاربر وارد صفحه خاصی شد، یک فایل JavaScript اجرا بشه.»

سریع میری سراغ نصب یک افزونه.

ولی افزونه ممکنه علاوه بر همون قابلیت، کلی چیز دیگه وارد سایت کنه:

CSS
JavaScript
Admin Assets
Database Options
Cron Jobs
AJAX Requests

و تو فقط برای یک قابلیت ساده، یک وابستگی جدید به پروژه اضافه کردی.

قبل از نصب افزونه، این سه سؤال رو بپرس:

۱. آیا واقعاً این قابلیت بدون افزونه قابل پیاده‌سازیه؟

۲. افزونه دقیقاً چه چیزهایی به سایت اضافه می‌کنه؟

۳. اگر فردا افزونه آپدیت نشه، پروژه چقدر بهش وابسته میشه؟

این به معنی «افزونه نصب نکن» نیست.

اتفاقاً افزونه خوب می‌تونه ساعت‌ها زمان توسعه رو ذخیره کنه.

بحث اینه که:

هر افزونه یک Dependency جدیده.

پس قبل از اینکه روی Install کلیک کنی، ببین واقعاً چه چیزی وارد پروژه‌ات می‌کنی.

@CodeVerse_dev

⚡چرا will-change رو نباید روی همه‌چی بذاری؟

یه ترفند CSS هست که خیلی‌ها وقتی انیمیشن سایت لگ می‌زنه سریع میرن سراغش:

.element {
    will-change: transform;
}

و فکر می‌کنن:

«خب، به مرورگر گفتم قراره تغییر کنه؛ پس حتماً سریع‌تر میشه.»

ولی قضیه این‌قدر ساده نیست.

حالا will-change به مرورگر می‌گه:

«خودت رو برای تغییر احتمالی این property آماده کن.»

اما اگر روی ده‌ها المان استفاده بشه، ممکنه مصرف منابع و حافظه بیشتر بشه و حتی Performance رو بدتر کنه.

پس این کار رو نکن:

* {
    will-change: transform;
}

😐

بهتره فقط برای المان‌هایی استفاده بشه که واقعاً قرار هست تغییر کنن؛ مخصوصاً در سناریوهای مشخص مثل Animation.

حتی در خیلی از موارد، اول باید ببینی مشکل واقعاً از کجاست و آیا transform، opacity یا ساختار انیمیشن درست استفاده شده یا نه.

قضیه Performance یعنی بهینه استفاده کردن از منابع، نه فعال کردن تمام گزینه‌های بهینه‌سازی.

@CodeVerse_dev

🛡️یک Worm زنجیره تأمین، صدها پکیج npm را آلوده کرد!

اگر با JavaScript کار می‌کنی، احتمالاً از npm استفاده کردی.

حالا npm چیست؟

مدیر پکیج JavaScript است که پروژه‌ها از طریق آن کتابخانه‌ها و وابستگی‌های خود را نصب می‌کنند.

اما اتفاق اخیر جدی است:

یک Worm مرتبط با اکوسیستم Keyv صدها نسخه از پکیج‌های npm را آلوده کرده و در برخی موارد به دنبال سرقت Credentialهای توسعه‌دهنده و CI/CD بوده است. گزارش‌های اولیه حداقل 353 نسخه آلوده در 79 نام پکیج را تأیید کرده‌اند.

🚨 چرا این اتفاق خطرناک است؟

چون ممکن است کد مخرب مستقیماً وارد پروژه تو نشده باشد؛ بلکه از طریق یک Dependency وارد شده باشد.

یعنی:

Your Code
   ↓
Dependency
   ↓
Dependency's Dependency
   ↓
Malicious Package

💡 نکته حرفه‌ای:

فقط به کدی که خودت نوشته‌ای اعتماد نکن؛ زنجیره Dependencyهای پروژه هم بخشی از سطح حمله است.

برای پروژه‌های مهم:

✅ حتما Dependencyها را Pin کن.
✅ همینطور Lockfile را Commit کن.
✅ قبل از Update پکیج‌ها بررسی امنیتی انجام بده.
✅ دسترسی Tokenها و Secretهای CI را محدود کن.

@CodeVerse_dev

‏⚛️ یه روش ساده برای ارتباط بین کامپوننت‌های React!

اگه چند کامپوننت داری که مستقیماً به همدیگه وصل نیستن، می‌تونی به‌جای Prop Drilling یا Stateهای پیچیده از Event Bus استفاده کنی.

این روش برای چیزهایی مثل Modal، Notification و قابلیت‌های Real-Time می‌تونه خیلی کاربردی باشه و پیاده‌سازی نسبتاً ساده‌ای هم داره. 👌

📎 Article

@CodeVerse_dev

🧠 یه اشتباه کوچیک در JavaScript که توی پروژه‌های بزرگ می‌تونه گرون تموم بشه

فرض کن یه تابع داری که قراره اطلاعات کاربر رو پردازش کنه.

خیلی‌ها این کار رو می‌کنن:

function processUser(user) {
    if (!user) return;

    // ...
}

در ظاهر مشکلی نداره.

ولی پروژه که بزرگ بشه، همین ifهای پراکنده تبدیل میشن به یک کابوس.

هر تابع باید مدام احتمال null یا undefined بودن ورودی رو بررسی کنه.

اینجاست که یک اصل مهم وارد میشه:

Validate at the boundary.

یعنی داده رو همون جایی که وارد سیستم میشه اعتبارسنجی کن.

مثلاً:

API
 ↓
Validation
 ↓
Business Logic
 ↓
Database

نه اینکه هر تابع وسط سیستم دوباره از خودش بپرسه:

«نکنه این مقدار null باشه؟» 😅

این موضوع در پروژه‌های بزرگ باعث میشه:

✅ کد قابل پیش‌بینی‌تر بشه
✅ تعداد شرط‌های تکراری کم بشه
✅راحت‌تر Debug کردن
✅ مسئولیت هر لایه مشخص‌تر باشه

💡 کد حرفه‌ای فقط کدی نیست که کار می‌کنه؛ کدیه که بعد از بزرگ شدن پروژه هم قابل کنترل باقی می‌مونه.

@CodeVerse_dev

🔐 یه مشکل امنیتی وردپرس که باید جدی بگیری

اگه از افزونه User Profile Builder استفاده می‌کنی، حتماً نسخه افزونه‌ات رو بررسی کن.

یک آسیب‌پذیری جدی در این افزونه گزارش شده که می‌تونه در شرایط خاص، امکان دسترسی غیرمجاز به حساب‌های Administrator رو فراهم کنه.

موضوع مهم اینه که:

مهاجم لزوماً نباید اول وارد پنل مدیریت شده باشه.

یعنی یک افزونه ظاهراً ساده مربوط به پروفایل کاربران می‌تونه تبدیل به نقطه ورود مهاجم بشه.

این دقیقاً یکی از دلایلیه که می‌گیم:

❌ «افزونه نصب شده ولی استفاده نمی‌کنیم» → دلیل خوبی برای نگه داشتنش نیست.

اگر افزونه‌ای لازم نداری:

حذفش کن، نه اینکه فقط غیرفعالش کنی.

و برای افزونه‌های مهم هم همیشه نسخه جدید رو از منبع رسمی بررسی کن.

💡 امنیت وردپرس فقط نصب یک Security Plugin نیست؛ مدیریت سطح حمله سایته.

@CodeVerse_dev

حق😂😭

🚀 تازگیا Chrome DevTools یه آپدیت خیلی کاربردی گرفته؛ مخصوصاً برای Frontend Developerها

توی Chrome 152 چند قابلیت جالب به DevTools اضافه شده که ارزش امتحان کردن دارن.

یکی از مهم‌ترین‌ها:

Soft Navigation Metrics

حالا می‌تونی معیارهای عملکرد مربوط به Navigationهای نرم داخل SPAها رو بهتر بررسی کنی.

یعنی برای سایت‌هایی که با React، Vue یا سایر معماری‌های SPA ساخته شدن، تحلیل Performance دقیق‌تر میشه.

از اون طرف، ابزارهای Debugging برای Nested CSS هم بهتر شدن.

این یعنی وقتی CSSهای تو در تو و مدرن استفاده می‌کنی، پیدا کردن اینکه دقیقاً کدوم Rule روی المنت اثر گذاشته راحت‌تر میشه.

💡 نکته جالب اینجاست که DevTools دیگه فقط ابزار Debug نیست؛ داره تبدیل میشه به یکی از مهم‌ترین ابزارهای تحلیل واقعی تجربه کاربر.

اگه Frontend کار می‌کنی، آپدیت‌های DevTools رو دست‌کم نگیر.

@CodeVerse_dev

🚀 یک نکته درباره Cache که خیلی از پروژه‌ها دیر متوجهش می‌شوند

عملیات Cache کردن یک Query ساده است.

مشکل واقعی زمانی شروع می‌شود که داده تغییر کند.

فرض کنید:

Product → price = 500

این مقدار Cache شده.

حالا قیمت در Database می‌شود:

700

اما Cache هنوز 500 را برمی‌گرداند.

اینجاست که مسئله اصلی Cache مطرح می‌شود:

Cache Invalidation

چه زمانی Cache را حذف کنیم؟
چه زمانی Update کنیم؟
مقدار TTL چقدر باشد؟
اگر چند Server داشته باشیم چه؟
اگر دو Request هم‌زمان Cache را تغییر دهند چه؟

به همین دلیل:

عمل Cache کردن مشکل Performance را حل می‌کند؛ اما Cache Invalidation یک مسئله معماری است.

و همان جمله معروف هنوز پابرجاست:

There are only two hard things in Computer Science: cache invalidation and naming things.

@CodeVerse_dev

⚡ چطور بعضی سایت‌ها با سرور قوی هم کند هستند؟

چون Performance فقط CPU و RAM نیست.

ممکن است سرور شما کاملاً قدرتمند باشد، اما کاربر همچنان منتظر بماند.

مسیر یک Request را تصور کنید:

Browser
↓
DNS
↓
CDN
↓
Load Balancer
↓
Application
↓
Database
↓
External API

کندی می‌تواند در هرکدام از این نقاط اتفاق بیفتد.

مثلاً اگر Application در 100ms پاسخ بدهد اما یک API خارجی 2 ثانیه طول بکشد، ارتقای CPU تقریباً هیچ کمکی نمی‌کند.

برای همین در سیستم‌های حرفه‌ای، به جای حدس زدن باید Latency را در تمام مسیر اندازه‌گیری کرد.

Metrics → Tracing → Profiling

اول پیدا کن کجا کند است؛ بعد تصمیم بگیر چه چیزی را باید بهینه کنی.


@CodeVerse_dev