لطفا همتون اینجا جوین شید
https://t.me/khabarNcPqH

اطلاعیه همگانی

درود خدمت تمام دوستان

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

بیانیه بخش 276

درود بر دانشجویان، نخبگان، و جنگجویان سایبری

بعد از سال ها زنده بودن در ایران اونچه مشخص و واضحه آموزش دچار مشکل و مسیر نامشخص،اکثریت فضای درسو مدرسه رو داشتید و حتی دانشگاه و عده ای هم سربازی یا شغلو درامد...
علم کامپیوتر مسئله مهم در جهت توسعه و مدیریت و... همیشه در اولین اصول یادگیری بوده اما فضای یادگیری مسموم و روش های تکراری و خلاف آموزش های مدرن بوده
چندین بار اعلام کردیم قصد داریم مجدد فعالیت کنیم این یعنی قبلا هم فعالیت کردیم اما در حالت ها کوچک و خصوصی و اونچه مشخصه اکثریت پیشرفت هایی داشتن که در راه درست و با هدف بوده در کنار هم قصد داریم فعالیت و انجمنی فعال داشته باشید و در هر موضوعی از این علم اونچه در فهم داریم با هم به اشتراک و درواقع تبادل کنیم

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

https://t.me/+LIeyXub4kdFmMjA0

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

https://t.me/+qlfg5PwaWV0xNGQ8

نکته بزودی لینک باطل میشه...

در حال باطل شدن لینک...

https://t.me/Shab_Tab_TM
start👌

درود خدمت همه رفقا

یه چند جمله ای حرف دارم میگم و باقیش با خودتون

اول اینکه این نظر سنجی رو که جوابتون بله بوده پیگیر شید مشکلتون حل بشه خیلی اهمیت داره مخصوصن فضای صفر و یک
دوم اینکه تنها سنی که افراد بتونن به رشد کامل و صبر هیجان انگیزه و حوصله واسه انجام کاری داشته باشن از ۳ تا ۲۰ سالگیه اسمشو بزار دوران طلایی اگه بچه دارید خواهر برادر یا هر کسی اگه در توانتون هست حمایتشون کنید البته گاهی حمایت های اشتباه جلو پیشرفتو میگیره... پول تو این دوران جز کار راه انداختن نقش خاصی نداره اما از حد که بگذره جلو رشد گرفته میشه...
اگه وقت شد هر کدوم از حرفایی که میزنم بیشتر راجبش توضیح میدم البته اگه ریکشن زدین و تمایلی به خوندن حرفام داشته باشید...

عضو شید شروع اینجاست

درود وقت بخیر دوستان همینطور که می دونید مدتیه فعالیتو شروع کردیم و در کانال ازمون فعالیت می کنیم شروع فعالیت اونجا بود و به ترتیب در سایر شبکه ها و کانال ها نیز فعالیت خواهیم کرد اما نیاز به حمایتتون داریم و لطفا در ازمون های این کانال شرکت کنید
https://t.me/Network_Delta

--
### فراتر از کدنویسی؛ هنر معماری با اصل Single Responsibility (SRP)

در دنیای برنامه‌نویسی وب، نوشتن کدی که «کار کند» فقط ۲۰ درصد ماجراست. ۸۰ درصد باقی‌مانده، توانایی نگهداری (Maintenance) و توسعه‌‌پذیری آن کد است. امروز به سراغ اولین و مهم‌ترین اصل از اصول SOLID می‌رویم.

#### 🛠 اصل مسئولیت واحد (SRP) چیست؟
این اصل می‌گوید: «هر کلاس یا ماژول باید فقط و فقط یک دلیل برای تغییر داشته باشد.»

به زبان ساده: یک قطعه کد نباید همزمان هم با دیتابیس حرف بزند، هم محاسبات ریاضی انجام دهد و هم خروجی را برای کاربر نمایش دهد!

#### ❌ نمونه کد غیرحرفه‌ای (Spaghetti Code):
در این مثال، یک کلاس هم وظیفه مدیریت کاربر و هم وظیفه اعتبارسنجی و ذخیره در فایل را دارد:

class User {
  constructor(name, email) {
    this.name = name;
    this.email = email;
  }

  // مدیریت داده‌های کاربر
  saveToDatabase() {
    console.log(`Saving ${this.name} to DB...`);
  }

  // اعتبارسنجی - این وظیفه کلاس User نیست!
  validateEmail() {
    return this.email.includes('@');
  }

  // نمایش - این هم وظیفه این کلاس نیست!
  showProfile() {
    return `<h1>${this.name}</h1>`;
  }
}

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

// ۱. کلاس موجودیت کاربر (فقط داده)
class User {
  constructor(name, email) {
    this.name = name;
    this.email = email;
  }
}

// ۲. سرویس اعتبارسنجی
class UserValidator {
  static validateEmail(email) {
    return email.includes('@');
  }
}

// ۳. سرویس ذخیره‌سازی (Persistance)
class UserRepository {
  save(user) {
    console.log(`Saving ${user.name} to Database...`);
  }
}

// ۴. سرویس نمایش (UI/Presentation)
class UserView {
  renderProfile(user) {
    return `<div>User: ${user.name}</div>`;
  }
}

#### 🚀 چرا این سبک کدنویسی برای شما مهم است؟
۱. تست‌پذیری: تست کردن یک تابع کوچک که فقط یک کار انجام می‌دهد، بسیار راحت‌تر است.
۲. کاهش باگ: وقتی تغییری در بخش دیتابیس ایجاد می‌کنید، خیالتان راحت است که بخش UI خراب نمی‌شود.
۳. کار تیمی: در پروژه‌های بزرگ (مثل پروژه‌های درس آزمایشگاه مهندسی نرم‌افزار)، هر کس می‌تواند روی یک بخش مستقل کار کند.

---
#برنامه_نویسی #مهندسی_نرم_افزار #CleanCode #SOLID #WebDevelopment #شب_تاب

@init_code هزاران آموزش برنامه نویسی

کدنویسی امن؛ چرا نباید هرگز به ورودی‌های کاربر اعتماد کرد؟

در دنیای توسعه نرم‌افزار، شکاف بزرگ میان یک «کدنویس» و یک «مهندس نرم‌افزار»، در نحوه برخورد با داده‌های ورودی است. امنیت یک سیستم، قبل از آنکه به فایروال‌ها وابسته باشد، به کیفیت کدهایی که می‌نویسیم بستگی دارد.

#### 🛡 اصل طلایی: Never Trust User Input
فرقی نمی‌کند شما یک فرم تماس ساده می‌سازید یا یک API پیچیده؛ هر داده‌ای که از سمت کاربر می‌آید (پارامترهای URL، بدنه درخواست‌های POST، یا حتی هدرها) می‌تواند سمی باشد.

#### ❌ رویکرد خطرناک (آسیب‌پذیر در برابر SQL Injection):
بسیاری از توسعه‌دهندگان مبتدی، ورودی کاربر را مستقیماً در کوئری‌های پایگاه داده قرار می‌دهند:

// بسیار خطرناک!
const userId = req.body.id;
const query = `SELECT * FROM users WHERE id = ${userId}`; 
db.execute(query);

*در این حالت، یک نفوذگر می‌تواند با وارد کردن مقداری مثل 1 OR 1=1 به تمام اطلاعات دیتابیس دسترسی پیدا کند.*

#### ✅ رویکرد حرفه‌ای (استفاده از Prepared Statements):
در سطح مهندسی، ما از پارامتریزه کردن کوئری‌ها استفاده می‌کنیم تا موتور پایگاه داده، ورودی را فقط به عنوان «داده» ببیند، نه بخشی از دستورات اجرایی:

// ایمن و حرفه‌ای
const userId = req.body.id;
const query = "SELECT * FROM users WHERE id = ?";
db.execute(query, [userId]); 

#### 🛠 سه گام برای افزایش امنیت در پروژه‌های وب:

1. Validation (اعتبارسنجی): چک کنید که آیا داده اصلاً فرمت درستی دارد؟ (مثلاً ایمیل واقعاً ایمیل است؟)
2. Sanitization (پاک‌سازی): حذف کاراکترهای خطرناک (مانند <script> یا کدهای SQL) از ورودی‌ها.
3. Principle of Least Privilege: اپلیکیشن شما باید با کمترین دسترسی ممکن به دیتابیس متصل شود. (مثلاً دسترسی حذف یا Drop کردن جداول را نداشته باشد).

#### 💡 نتیجه‌گیری برای توسعه‌دهندگان:
امنیت یک ویژگیِ الحاقی (Add-on) نیست که در پایان پروژه به آن فکر کنیم؛ امنیت باید در تار و پود کدهای ما تنیده شده باشد. با رعایت همین نکات ساده، جلوی بیش از ۸۰٪ حملات رایج وب گرفته می‌شود.

---
#برنامه_نویسی #امنیت_نرم_افزار #WebSecurity #SQLInjection #CleanCode #توسعه_وب #شب_تاب

---

@init_code هزاران آموزش برنامه نویسی

### هنر سکوت در کدنویسی؛ چه زمانی و چگونه کامنت بنویسیم؟

در دنیای برنامه‌نویسی یک جمله معروف وجود دارد: «کدِ خوب مثل یک جکِ خوب است؛ اگر مجبور شوید آن را توضیح دهید، یعنی به اندازه کافی خوب نیست!»

اما واقعیت این است که حتی بهترین کدهای دنیا هم گاهی به توضیح نیاز دارند. مرز بین «کامنت‌گذاری حرفه‌ای» و «کامنت‌گذاری آزاردهنده» کجاست؟

#### ❌ اشتباه رایج: توضیحِ بدیهیات (Redundant Comments)
بسیاری از کدنویس‌ها عادت دارند دقیقاً همان چیزی که کد انجام می‌دهد را بنویسند. این کار فقط حجم فایل را زیاد و تمرکز را کم می‌کند:

// دریافت نام کاربر از ورودی
const userName = getName(); 

// حلقه برای پیمایش لیست محصولات
for (let i = 0; i < products.length; i++) {
  // اضافه کردن قیمت به مجموع
  total += products[i].price;
}

*این کامنت‌ها هیچ ارزشی ندارند، چون خودِ کد به وضوح دارد همین را می‌گوید.*

#### ✅ رویکرد حرفه‌ای: توضیحِ «چرا» به جای «چیستی»
کد شما می‌گوید «چه اتفاقی» می‌افتد، اما کامنت باید بگوید «چرا این اتفاق» می‌افتد. از کامنت برای توضیح منطق‌های پیچیده، تصمیمات بیزنسی یا رفع باگ‌های خاص استفاده کنید:

// به دلیل محدودیت API درگاه بانکی، مبالغ باید به ریال تبدیل شوند
// و سقف تراکنش نباید از ۵۰ میلیون فراتر برود.
if (amount > 50000000) {
  throw new Error("سقف تراکنش رعایت نشده است");
}

#### 🛠 ۳ قانون طلایی برای مستندسازی حرفه‌ای:

1. کدِ خود-توضیح‌دهنده (Self-Documenting): به جای اینکه برای یک متغیر با نام مبهم کامنت بگذارید، نام متغیر را اصلاح کنید.
- ❌ let d = 30; // تعداد روزهای انقضا
- ✅ let daysUntilExpiration = 30;

2. استفاده از JSDoc یا استانداردهای مشابه: برای توابع و کلاس‌ها از فرمت‌های استانداردی استفاده کنید که ادیتورها (مثل VS Code) بتوانند آن‌ها را تشخیص دهند:

    /**
     * محاسبه تخفیف بر اساس سطح کاربری
     * @param {number} price - قیمت اصلی محصول
     * @param {string} rank - رتبه کاربر (Gold, Silver, Bronze)
     * @returns {number} قیمت نهایی پس از کسر تخفیف
     */
    function calculateDiscount(price, rank) { ... }
    

3. کامنت‌های TODO: برای کارهایی که باید در آینده انجام شوند، از تگ // TODO: استفاده کنید تا تیم بداند چه بخش‌هایی نیاز به تکمیل دارد.

#### 💡 نتیجه‌گیری:
بهترین کامنت، کدی است که به کامنت نیاز نداشته باشد. اما وقتی منطق کار پیچیده می‌شود، کامنتِ شما باید مثل یک نقشه‌ راه برای برنامه‌نویس بعدی (یا خودتان در ۶ ماه آینده) عمل کند.

#برنامه_نویسی #CleanCode #Documentation #Refactoring #مهندسی_نرم_افزار #کدنویسی #شب_تاب

---

@init_code هزاران آموزش برنامه نویسی

### بدهی فنی (Technical Debt)؛ قاتل خاموش پروژه‌های نرم‌افزاری

در دنیای مهندسی نرم‌افزار، ما مدام با یک دوراهی مواجهیم: «سرعت» یا «کیفیت»؟
وقتی برای رساندن پروژه به ضرب‌الاجل (Deadline)، از استانداردهای کدنویسی صرف‌نظر می‌کنیم، در واقع در حال گرفتن یک وام هستیم؛ وامی که به آن «بدهی فنی» می‌گویند.

#### ❓ بدهی فنی دقیقاً چیست؟
تصور کنید برای راه‌اندازی سریع یک قابلیت، به جای طراحی یک معماری اصولی، از کدهای کپی-پیست شده و راه‌حل‌های موقتی (Quick Fixes) استفاده می‌کنید. کار شما راه می‌افتد، اما این کدِ ضعیف، «بدهی» شماست. مانند هر وامی، این بدهی هم «بهره» (Interest) دارد. بهره‌ٔ آن، زمانی است که در آینده باید صرف دست‌وپنجه نرم کردن با باگ‌های عجیب و سخت شدن توسعه قابلیت‌های جدید کنید.

#### 🛠 انواع بدهی فنی:

1. بدهی عمدی: وقتی آگاهانه برای رسیدن به بازار (Time to Market) کیفیت را فدا می‌کنیم (باید در اولین فرصت بازپرداخت شود).
2. بدهی فرسایشی: کدی که در زمان خودش خوب بوده، اما با گذشت زمان و تغییر تکنولوژی، قدیمی و ناکارآمد شده است.
3. بدهی ناشی از بی‌تجربگی: زمانی که تیم به دلیل عدم تسلط بر الگوهای طراحی (Design Patterns)، کدی غیراستاندارد تولید می‌کند.

#### ❌ نشانه‌های بالا رفتن بدهی فنی در یک پروژه:
- اضافه کردن یک ویژگی ساده، هفته‌ها زمان می‌برد.
- با اصلاح یک باگ، سه جای دیگر پروژه خراب می‌شود.
- تیم از دست زدن به کدهای قدیمی می‌ترسد (Legacy Code).

#### ✅ چگونه بدهی فنی را مدیریت کنیم؟

- رفکتورینگ (Refactoring) مستمر: بخشی از زمان هر اسپرینت یا هفته کاری را به تمیز کردن کدهای قبلی اختصاص دهید.
- تست‌نویسی (Unit Testing): تست‌های خودکار مثل یک ترمز عمل می‌کنند و اجازه نمی‌دهند بدهی فنی از حد مجاز فراتر برود.
- مستندسازی تصمیمات: بنویسید که چرا فلان بخش را موقتاً این‌طور پیاده کرده‌اید تا آیندگان (یا خودِ آینده‌تان) گیج نشوند.

#### 💡 نتیجه‌گیری:
بدهی فنی به خودیِ خود بد نیست؛ گاهی برای تجارت لازم است. اما اگر مدیریت نشود، پروژه شما به نقطه‌ای می‌رسد که هزینه‌ نگهداری‌اش از هزینه بازنویسی کامل آن بیشتر می‌شود (ورشکستگی فنی).

#برنامه_نویسی #مهندسی_نرم_افزار #TechnicalDebt #بدهی_فنی #مدیریت_پروژه #CleanCode #شب_تاب

---

@init_code هزاران آموزش برنامه نویسی

🚀 فعالیت رسمی مجموعه‌ی «شب‌تاب» در تمامی کانال‌های تخصصی آغاز شد!

برای دسترسی به آموزش‌های دسته‌بندی شده و به‌روز در حوزه‌های مختلف تکنولوژی، همین حالا در کانال‌های زیر عضو شوید:

💻 آموزش کامپیوتر و ICDL:
@MASTERAPS

🤖 هوش مصنوعی و ابزارهای نوین:
@ai_adnvanced

👨‍💻 برنامه‌نویسی و توسعه‌دهندگی:
@init_code

🛡 شبکه و امنیت تخصصی:
@Network_adnvanced

📝 آزمون‌ها و کوییزهای IT:
@ShabtabQuiz

---
✨ با دنبال کردن تمامی کانال‌ها، هیچ آموزشی را از دست ندهید. دنیای تکنولوژی اینجاست!

📌 #شب_تاب #تکنولوژی #آموزش #برنامه_نویسی #هوش_مصنوعی #شبکه #امنیت

🍝 اسپاگتی کد و بدهیِ فنی؛ وقتی مثلِ گاو فقط کد می‌زنی!

ببین، یه سری برنامه‌نویس داریم که فکر می‌کنن چون کُدشون "کار می‌کنه"، دیگه یعنی شاهکار کردن! آخه لاشخور! اگه کدی زدی که فردا خودت هم نمی‌تونی بفهمی چی به چیه، تو برنامه‌نویس نیستی، تو یه «تایپیستِ متوهمی» که داری یه بمبِ ساعتی می‌سازی.

💀 داستان چیه؟ (بدهیِ فنی یا Technical Debt)
بدهی فنی یعنی تو واسه اینکه سریع کار رو تحویل بدی، از راهِ کثیف و میان‌بُر میری. مثل اینه که واسه ساختنِ خونه، جای تیرآهن از چوبِ کبریت استفاده کنی. اولش خونه سرپاست، ولی یه باد بیاد، کلِ هیکلِ پروژه به فاک میره.

چطوری گند می‌زنن به پروژه؟
۱. اسپاگتی کد: کدها رو جوری به هم گره می‌زنن که اگه یه if رو این‌ور تغییر بدی، یهو دیتابیسِ اون‌ورِ دنیا منفجر میشه!
۲. Hard-coding: متغیرها و آدرس‌ها رو دستی می‌نویسن وسط کد. انگار مغزشون نمیکشه که اینا باید داینامیک باشن.
۳. نبودِ داکیومنت: طرف جوری کد می‌زنه انگار قراره فردا بمیره و رازش رو با خودش ببره تو گور. هیچکس نمی‌فهمه این فانکشنِ کص‌شعر قراره چه غلطی بکنه!

نتیجه؟
بعد از ۶ ماه، پروژه جوری سنگین و کثیف میشه که دیگه هیچ آپدیتِ ساده‌ای نمیشه داد. هر تغییری مساوی با ۱۰۰ تا باگِ جدیده‌. اینجاست که صاحبِ پروژه باید کلِ اون کدهایِ آشغال رو بریزه دور و از اول شروع کنه. یعنی پول و زمانِ ملت رو دادی دستِ یه مشت اَجق‌وَجق!

⚠️ چرا اینا برنامه‌نویس نیستن؟
چون این کص‌مغزها هنوز نمی‌فهمن که کد رو برای آدمیزاد می‌نویسن، نه برای ماشین! ماشین هر آشغالی رو اجرا می‌کنه، ولی این هنرِ توئه که جوری بنویسی که بقیه هم بتونن توسعه‌اش بدن. اینا همونایی هستن که فرقِ SOLID و KISS رو با مارکِ پوشکِ بچه‌شون نمی‌دونن!

🛠️ راهِ نجات (اگه نمی‌خوای یه بازنده باشی):
- Clean Code: برو کتابِ کُلین کد رو بخون تا بفهمی چطوری مثل آدم اسم‌گذاری کنی و فانکشن بنویسی.
- Refactoring: همیشه وقتی کد می‌زنی، برگرد و تمیزش کن. نذار زباله‌ها روی هم جمع بشن.
- Design Patterns: الگوهای طراحی رو یاد بگیر که چرخ رو از اول اختراع نکنی (اونم مربع!).
- TDD: قبل از اینکه کدِ کثیف بزنی، براش تست بنویس که بفهمی داری چه گوهی می‌خوری.

#TechnicalDebt #CleanCode #SpaghettiCode #Programming #Refactoring #برنامه_نویس_بی_عرضه

---
اگه با این پست حال کردی و فهمیدی که تا حالا داشتی آشغال تولید می‌کردی، اون انگشتِ مبارکت رو فشار بده رو ریکشن‌ها. حمایت نکنی، باگ‌های کدِ قبلیت میاد تو خوابت خفه‌ات می‌کنه! 😂🖕
@init_code