در برنامه‌نویسی، اصطلاح "Idiomatic" به معنای استفاده از الگوها و روش‌هایی است که در یک زبان برنامه‌نویسی خاص به عنوان استاندارد و رایج شناخته می‌شوند. این موضوع اهمیت زیادی دارد و چندین دلیل برای آن وجود دارد:

1. خوانایی کد: کدی که به صورت idiomatic نوشته شده باشد، برای سایر برنامه‌نویسانی که با آن زبان آشنا هستند، راحت‌تر قابل درک است. این باعث می‌شود که تیم‌ها به راحتی بتوانند با یکدیگر همکاری کنند.

2. نگهداری آسان‌تر: کدی که از الگوهای استاندارد پیروی می‌کند، به راحتی قابل نگهداری و اصلاح است. این امر به‌ویژه در پروژه‌های بزرگتر که افراد مختلفی روی آن کار می‌کنند، بسیار مهم است.

3. عملکرد بهتر: در بسیاری از موارد، استفاده از روش‌های idiomatic به بهبود عملکرد کمک می‌کند، زیرا این روش‌ها اغلب بهترین شیوه‌های بهینه‌سازی شده برای زبان مربوطه هستند.

4. کاهش خطاها: پیروی از الگوهای رایج به کاهش خطاها و باگ‌ها کمک می‌کند، زیرا این الگوها معمولاً توسط جامعه توسعه‌دهندگان آزمایش شده‌اند و مطمئن‌تر هستند.

#idiomatic

@Syntax_fa

Backpressure

تو این پست با چند مثال Backpressure رو بررسی میکنیم.

مثال اول:‌کارخانه شکلات
در برنامه تلویزیونی "I Love Lucy" قسمتی وجود دارد که Lucy در یک کارخانه بسته‌بندی شیرینی کار می‌کند. وظیفه او برداشتن شیرینی از نوار نقاله و بسته‌بندی هر کدام در کاغذ است.
او با این مشکل مواجه می شود که تعداد شیرینی هایی که در نوار نقاله می أید بیشتر از توان او در بسته بندی است.

او دو روش مختلف برای مقابله با آن را امتحان می‌کند: کنار گذاشتن برخی تا بعدا بهشون رسیدگی کنه (buffering)، و در نهایت شروع به خوردن و پنهان کردن آنها در کلاهش می‌کند (dropping). با این حال، در مورد یک کارخانه شکلات، هیچ یک از این استراتژی‌های Backpressure عملی نیستند. در عوض، او نیاز داشت که نوار نقاله را آهسته‌تر کنند؛ به عبارت دیگر، او نیاز به کنترل سرعت producer دارد.

مثال دوم: خواندن و نوشتن از فایل:
حالا درباره Backpressure مرتبط با نرم‌افزار صحبت می‌کنیم. رایج‌ترین حالت هنگام کار با file system است.

نوشتن در فایل کندتر از خواندن فایل است. تصور کنید یک hard drive که سرعت موثر خواندن ۱۵۰ مگابایت بر ثانیه و سرعت نوشتن ۱۰۰ مگابایت بر ثانیه را ارائه می‌دهد. اگر بخواهید فایلی را با حداکثر سرعت ممکن به memory بخوانید، در حالی که همزمان آن را با حداکثر سرعت ممکن به دیسک بنویسید - باید هر ثانیه ۵۰ مگابایت را buffer کنید. در هر ثانیه 50 مگابایت را باید بافر کنید!

شما نمی‌توانید به بافر رسیدگی کنید تا زمانی که خواندن فایل ورودی کاملاً به پایان برسد.

حالا تصور کنید این کار را با یک فایل ۶ گیگابایتی انجام می‌دهید. تا زمانی که فایل را کاملاً خوانده‌اید، یک buffer ۲ گیگابایتی خواهید داشت که هنوز باید نوشتن آن را تمام کنید.

6 GB / 150 MB = 40 seconds
150 MB - 100 MB = 50 MB deficit
50 MB x 40 = 2 GB !!!

مقدار زیادی memory هدر رفته است. در برخی سیستم‌ها این ممکن است حتی از مقدار memory موجود فراتر رود.

نگران نباشید، راه‌حل ساده است: فقط به همان سرعتی بخوانید که می‌توانید بنویسید. تقریباً تمام I/O library ها abstraction هایی را برای انجام خودکار این کار برای شما ارائه می‌دهند.

مثال سوم: ارتباط Server
مثال بعدی ارتباط بین server ها است. امروزه استفاده از معماری microservice که در آن مسئولیت‌ها بین چندین server تقسیم می‌شود بسیار رایج است.

Backpressure
معمولاً این سناریو زمانی رخ می‌دهد که یک server درخواست‌ها را سریع‌تر از آنچه server دیگر می‌تواند پردازش کند، ارسال می‌کند.

اگر server A، ۱۰۰ rps (requests per second) به server B بفرستد، اما server B فقط بتواند ۷۵ rps را پردازش کند، شما یک کسری ۲۵ rps دارید.

در هر صورت، server B باید به نوعی با Backpressure مقابله کند. Buffer کردن آن کسری ۲۵ rps یک گزینه است، اما اگر آن افزایش ثابت بماند، به زودی memory تمام می‌شود و از کار می‌افتد. Drop کردن درخواست‌ها گزینه دیگری است که در اکثر سناریو ها قابل قبول نیست.

گزینه ایده‌آل این است که server B نرخ ارسال درخواست‌های server A را کنترل کند، اما باز هم این همیشه عملی نیست - اگر server A به نمایندگی از یک کاربر درخواست می‌کند، شما نمی‌توانید کاربر ها را کنترل کنید که آهسته‌تر شوند، اغلب بهتر است که server درخواست کننده buffer داشته باشد، تا بتوانید بار memory را در downstream، جایی که استرس وجود دارد، بهتر توزیع کنید و بر سایر درخواست کنندگان تأثیر نگذارید.

به عنوان مثال، اگر سه نوع مختلف سرویس (A, B, C) همگی به یک سرویس downstream مشترک (Z) درخواست بدهند، و یکی از آنها (A) تحت بار بالا باشد، سرویس Z می‌تواند به طور موثر به سرویس A بگوید "آهسته‌تر شو" (کنترل producer) که باعث می‌شود سرویس A درخواست‌ها را buffer کند. اگر این ادامه پیدا کند، در نهایت سرویس A با کمبود memory مواجه می‌شود، با این حال، دو سرویس دیگر (B, C) همچنان فعال می‌مانند، همانطور که سرویس downstream Z نیز فعال می‌ماند زیرا اجازه نمی‌دهد یک سرویس بدرفتار از دسترسی برابر برای دیگران جلوگیری کند. در این مورد ممکن است قطعی اجتناب‌ناپذیر باشد، اما ما محدوده را محدود کردیم و از Denial of Service زنجیره‌ای جلوگیری کردیم.

مثال ها:
https://medium.com/@jayphelps/backpressure-explained-the-flow-of-data-through-software-2350b3e77ce7

#Backpressure

@Syntax_fa

وقتی به جای سیستم‌ها، انسان‌ها هک می‌شوند!

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

https://youtu.be/Z_S9jFkdCjY

@Syntax_fa

یه تنوعی بدین به خودتون😂🔥

VsCode Extention : power mode

برنامه نویسا روزی یبار به چی فکر می کنن:

#fun

@Syntax_fa

مشکل خود سنیور پنداری!

جدیدا خیلیا رو میبینم که قبل از تخصصشون عنوان سنیور رو وصل میکنن. ولی واقعیت امر اینه که سنیور بودن یه لقب نیست. به زمان هم خیلی بستگی نداره که بعد از فعالیت n ساله در یک زمینه شما به این مرحله برسید.
کسی که خودش رو سنیور خطاب میکنه در واقع مهارت های خیلی زیادی رو باید داشته باشه که یکیشون برنامه نویسیه!
مهارت های نرم، مهارت یادگیری چیزهای جدید، طرز فکر و راهکار یابی و ... بخشی از پیشنیاز این صفت میشه.
تو فرایند جذب نیروی جدید برای شرکتمون رزومه های زیادی رو چک کردم و واقعا همه دوست دارن این عنوان رو قبل اسمشون داشته باشن.
عجیب ترین چیزی که دیدم هم مربوط میشه به یه فردی که بعد از یه بوت کمپ با یه شرکت شروع به همکاری چند ماهه کرده بود و عنوان شغلی خودش تو اون شرکت رو نوشته بود "Senior Django Developer"!
یعنی در فاصله کمتر از چند ماه به این درجه از عرفان رسیده بوده!


@normal_developer

Hard Coding

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

مثال ساده:

# Hard coded example
deposit = 0.1 
price = 100
final_price = price + (price * deposit)
print(final_price)

مزایای Hard Coding
1. سادگی اولیه: کدنویسی سریع‌تر و آسان‌تر است، زیرا نیازی به ایجاد ساختارهای پیچیده برای مدیریت مقادیر نیست.
2. کاهش پیچیدگی در پروژه‌های کوچک: در برنامه‌های کوچک و ساده، ممکن است نیازی به طراحی سیستم‌های دینامیک برای مدیریت مقادیر نباشد.
3. کاهش وابستگی به منابع خارجی: در صورت hard coding، نیازی به مدیریت فایل‌های پیکربندی، پایگاه داده یا ورودی‌های خارجی وجود ندارد.

معایب Hard Coding
1. کاهش انعطاف‌پذیری: تغییر مقادیر ثابت نیازمند تغییر کد منبع و بازنویسی یا بازسازی برنامه است، که می‌تواند زمان‌بر باشد.
2. نگهداری سخت‌تر: در برنامه‌های بزرگ، مدیریت مقادیر hard coded دشوار است و می‌تواند باعث افزایش احتمال بروز خطا شود.
3. محدودیت در تنظیمات داینامیک: برنامه‌های مبتنی بر hard coding نمی‌توانند به راحتی خود را با شرایط یا محیط‌های مختلف سازگار کنند.

جایگزین‌ها برای Hard Coding
1. استفاده از فایل‌های تنظیمات (Config Files): ذخیره مقادیر در فایل‌های خارجی مانند JSON`، `YAML`، یا `INI.
2. دیتابیس: استفاده از دیتابیس برای مدیریت مقادیر پویا.
3. متغیرهای محیطی (Environment Variables): استفاده از متغیرهای سیستم‌عامل برای ذخیره مقادیر حساس مانند secret key.
4. ورودی‌های پویا از کاربر: گرفتن مقادیر از کاربر به‌صورت runtime.

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

#hard_coding

@Syntax_fa

نمونه‌هایی از وب‌سایت‌ها و شرکت‌های بزرگ که استانداردهای مشخص‌شده را رعایت نکرده‌اند

1. Dropbox
- مشکل: استفاده از یک متد HTTP (POST) برای همه درخواست‌ها
- توضیح:
در نسخه‌های اولیه API خود، تقریباً همه درخواست‌ها (حتی موارد مربوط به خواندن داده‌ها) را با متد POST انجام می‌داد. این در حالی است که طبق استاندارد HTTP، متدهای GET باید برای دریافت داده‌ها استفاده شوند و نیازی به ارسال داده در بدنه (Body) نیست.

2. Twitter
- مشکل: استفاده از Query String برای ارسال اطلاعات حساس
- توضیح:
  در نسخه‌های اولیه API توییتر، برخی از درخواست‌های احراز هویت (مانند ارسال کلید API یا Access Token) از طریق Query String انجام می‌شد. این روش باعث می‌شد که اطلاعات حساس در URL ذخیره شوند و در لاگ‌های سرور یا مرورگر ثبت شوند.

  چرا استاندارد نیست؟
  طبق اصول امنیتی، اطلاعات حساس باید در بدنه درخواست (Body) یا هدر (Header) ارسال شوند، نه در Query String.

3. GitHub
- مشکل: استفاده از Status Code 404 برای پنهان کردن اطلاعات
- توضیح:
گیت هاب در برخی از APIهای خود، وقتی کاربری به یک منبع غیرمجاز دسترسی پیدا می‌کند (مثلاً یک ریپازیتوری خصوصی)، به جای استفاده از کد وضعیت 403 Forbidden، کد 404 Not Found را برمی‌گرداند. این کار برای جلوگیری از افشای وجود منابعی که کاربر به آن‌ها دسترسی ندارد انجام می‌شود.

4. Facebook
- مشکل: عدم استفاده صحیح از محدودیت نرخ (Rate Limit) در برخی نسخه‌های اولیه API
- توضیح:
  در نسخه‌های اولیه API فیس‌بوک، محدودیت نرخ (Rate Limit) به صورت یکنواخت برای همه کاربران اعمال نمی‌شد و رفتار مشخصی برای درخواست‌های بیش از حد وجود نداشت. گاهی درخواست‌های اضافی به صورت موفقیت‌آمیز پاسخ داده می‌شدند، اما در برخی موارد دیگر خطای غیرشفاف بازگردانده می‌شد.

5. Instagram
- مشکل: استفاده از کد وضعیت 200 برای خطاها
- توضیح:
  در API اینستاگرام، در برخی از نسخه‌های قدیمی، خطاها (مانند درخواست‌های نامعتبر) با کد وضعیت 200 OK بازگشت داده می‌شدند و جزئیات خطا در بدنه پاسخ قرار می‌گرفت.

6. PayPal
- مشکل: استفاده از کدهای وضعیت غیررایج
- توضیح:
  در برخی پاسخ‌های APIهای قدیمی PayPal، کدهای وضعیت غیررایج یا غیرمستند (مانند 490) ارسال می‌شدند. این کدها در مستندات HTTP تعریف نشده‌اند و کلاینت‌ها نمی‌توانند به درستی آن‌ها را پردازش کنند.

7. Amazon S3
- مشکل: استفاده از کد وضعیت 200 برای پاسخ‌های جزئی
- توضیح:
  در برخی از عملیات S3 (مانند لیست کردن اشیاء در یک باکت بزرگ)، اگر پاسخ به دلیل محدودیت اندازه به صورت چندبخشی باشد (Partial Response)، همچنان کد وضعیت 200 OK بازگردانده می‌شود.

  چرا استاندارد نیست؟
  برای پاسخ‌هایی که تنها بخشی از داده‌ها را شامل می‌شوند، استاندارد HTTP کد 206 Partial Content را پیشنهاد می‌کند.

8. LinkedIn
- مشکل: ساختار غیریکسان در پاسخ‌های JSON
- توضیح:
در برخی از نسخه‌های قدیمی APIهای لینکدین، ساختار پاسخ‌های JSON در درخواست‌های مختلف یکنواخت نبود. مثلاً کلیدها در یک پاسخ به صورت snake_case و در پاسخ دیگر به صورت camelCase بودند.

چرا استاندارد نیست؟
یکی از اصول طراحی API این است که ساختار پاسخ‌ها باید یکنواخت باشد تا توسعه‌دهندگان بتوانند به راحتی آن‌ها را پردازش کنند.

9. Google Maps API
مشکل: ارسال داده‌های غیرضروری در پاسخ‌ها
- توضیح:
در برخی پاسخ‌های Google Maps API، مقادیر غیرضروری و اضافی که گاهی هیچ ارتباطی با درخواست کاربر ندارند، بازگردانده می‌شدند. این می‌تواند باعث افزایش حجم داده و تأخیر در پردازش شود.

@Syntax_fa

برنامه نویسا تو هند، چجوری کار پیدا میکنن

#fun

@Syntax_fa

قبل از DNS

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

1. حفظ کردن آدرس‌های IP
قبل از DNS، شما برای باز کردن سایت‌ها مجبور بودید آدرس‌های IP مثل 192.168.1.1 یا 216.58.214.14 رو تایپ کنید. مثلاً اگه می‌خواستید به یه سایت خاص برید، باید آدرس IP اون رو از جایی پیدا می‌کردید و دستی وارد می‌کردید. کاملاً منطقیه که خیلی‌ها دفترچه‌ای کنار دست‌شون داشتن و توش آدرس‌های IP مهم رو می‌نوشتن، چون حفظ کردن این اعداد اصلاً کار ساده‌ای نبود.

2. فایل HOSTS
کامپیوترها اون زمان یه فایل به اسم `hosts` داشتن که مثل دفترچه تلفن عمل می‌کرد. تو این فایل، آدرس IP‌ها به اسم‌های خاصی (اگه وجود داشت) نگاشت می‌شدن. مثلاً نوشته می‌شد:

93.184.216.34 example.com
216.58.214.14 google.com

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

3. کشف سایت‌ها؟ یه چالش واقعی!
یادمون باشه که اون زمان خبری از موتورهای جستجو مثل گوگل یا یاهو نبود. شما یا باید آدرس IP یه سایت رو از کسی می‌شنیدید، یا توی یه مجله یا کتاب می‌دیدید. اگه یه سایت جدید می‌خواستید پیدا کنید، باید امیدوار می‌بودید که کسی آدرسش رو بهتون بده.


4. مشکل هماهنگی
هر شبکه‌ای نسخه خودش از فایل hosts رو داشت. حالا اگه یه سایت جدید اضافه می‌شد یا تغییری توی یه آدرس IP رخ می‌داد، باید اون تغییر رو دستی به همه شبکه‌ها اطلاع می‌دادید. این هماهنگی برای شبکه‌های بزرگ‌تر شبیه یه کابوس بود.

#fun

@Syntax_fa

تایپ‌های مختلف DNS رکورد و کاربردهای آن‌ها

1. A Record (Address Record)

کاربرد:
این رکورد، نام دامنه را به آدرس IPv4 تبدیل می‌کند. این نوع رکورد یکی از رایج‌ترین و مهم‌ترین رکوردها در DNS است.

مثال:
اگر کاربری آدرس example.com را وارد کند، DNS با استفاده از رکورد A، آدرس IP مربوط به آن (مثلاً 93.184.216.34) را برمی‌گرداند.

موارد استفاده:
- اتصال نام دامنه به آدرس IPv4 سرور

2. AAAA Record

کاربرد:
مشابه رکورد A است، اما برای آدرس‌های IPv6 استفاده می‌شود.

مثال:
اگر نام دامنه example.com از رکورد AAAA استفاده کند، ممکن است به آدرس IPv6 مانند 2606:2800:220:1:248:1893:25c8:1946 اشاره کند.

موارد استفاده:
- اتصال دامنه به آدرس IPv6

3. CNAME Record (Canonical Name Record)

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

مثال:
اگر www.example.com یک رکورد CNAME داشته باشد که به example.com اشاره کند، تمامی درخواست‌ها به www.example.com به آدرس example.com هدایت می‌شوند.

موارد استفاده:
- تغییر مسیر زیردامنه‌ها.
- ساده‌سازی مدیریت DNS در صورت تغییر آدرس IP.

4. MX Record (Mail Exchange Record)

کاربرد:
این رکورد برای مشخص کردن سرورهای ایمیل دامنه استفاده می‌شود. رکورد MX مشخص می‌کند که ایمیل‌های ارسالی به دامنه باید به کدام سرور ارسال شوند.

مثال:
اگر رکورد MX برای example.com به mail.example.com اشاره کند، تمامی ایمیل‌ها به سرور mail.example.com ارسال می‌شوند.

موارد استفاده:
- تنظیم سرور ایمیل.
- مدیریت اولویت ارسال ایمیل (اولویت‌ها با اعداد مشخص می‌شوند).

5. TXT Record

کاربرد:
این رکورد برای ذخیره اطلاعات متنی استفاده می‌شود. معمولاً از آن برای تأیید مالکیت دامنه و اطلاعات امنیتی استفاده می‌شود.

مثال:
- تأیید مالکیت دامنه برای Google Search Console.
- پیاده‌سازی پروتکل‌های امنیتی مانند SPF، DKIM، و DMARC.

موارد استفاده:
- جلوگیری از اسپم و جعل هویت ایمیل.
- تأیید سرویس‌های خارجی.

6. NS Record (Name Server Record)

کاربرد:
این رکورد مشخص می‌کند که کدام سرورهای DNS مسئول مدیریت رکوردهای دامنه هستند.

مثال:
برای دامنه example.com، رکورد NS ممکن است به ns1.example.com و ns2.example.com اشاره کند.

موارد استفاده:
- تعیین سرورهای DNS اصلی یک دامنه.
- مدیریت و نگهداری رکوردهای دامنه.

7. SOA Record (Start of Authority)

کاربرد:
این رکورد اطلاعات پایه‌ای درباره دامنه و سرور DNS اولیه ارائه می‌دهد. SOA رکورد شامل اطلاعاتی مانند آدرس ایمیل مدیر دامنه و زمان به‌روزرسانی رکوردها است.

موارد استفاده:
- مشخص کردن سرور اصلی DNS.
- مدیریت به‌روزرسانی رکوردهای DNS.

8. PTR Record (Pointer Record)

کاربرد:
این رکورد برای جستجوی معکوس DNS استفاده می‌شود (تبدیل آدرس IP به نام دامنه). برخلاف رکورد A که دامنه را به IP تبدیل می‌کند، PTR آدرس IP را به نام دامنه تبدیل می‌کند.

موارد استفاده:
- تأیید هویت سرورها.
- جلوگیری از ارسال ایمیل‌های اسپم.

#DNS_records

@Syntax_fa

📊 رشد چشمگیر داده‌های بدون ساختار

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

افزایش حجم داده‌های بدون ساختار: یک روند بی‌سابقه
گزارش‌ها و تحقیقات نشان می‌دهند که حجم داده‌های بدون ساختار سالانه با نرخ متوسطی در حدود ۳۰ تا ۴۰ درصد رشد می‌کند. این میزان رشد در برخی صنایع، مانند رسانه‌های دیجیتال، شبکه‌های اجتماعی و فناوری‌های مبتنی بر IoT، حتی از این رقم هم فراتر می‌رود. این افزایش به دلایل متعددی رخ می‌دهد.

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

- تنوع داده‌ها:
این داده‌ها از نظر فرمت و نوع بسیار متنوع هستند. مدیریت داده‌های متنی، صوتی، تصویری و ویدئویی نیازمند ابزارها و الگوریتم‌های متفاوت است.

- تحلیل پیچیده: 
  برخلاف داده‌های ساختاریافته که به راحتی قابل جستجو و تحلیل هستند، داده‌های بدون ساختار نیازمند فناوری‌های پیشرفته‌ای مانند پردازش زبان طبیعی (NLP)، بینایی کامپیوتر (Computer Vision) و تحلیل صوت هستند.

تأثیر بلندمدت داده‌های بدون ساختار
رشد سریع داده‌های بدون ساختار نشان‌دهنده تغییر چشمگیر در نحوه تولید، ذخیره و استفاده از اطلاعات در دنیای دیجیتال است. با توجه به این‌که این داده‌ها بیش از ۸۰ درصد کل داده‌های جهان را تشکیل می‌دهند، سازمان‌ها و کسب‌وکارها ناگزیرند که به ابزارها و راهکارهای پیشرفته برای مدیریت و تحلیل آن‌ها روی بیاورند.

#unstructured_data

@Syntax_fa

📢 معرفی CONN_MAX_AGE در Django

متغیر CONN_MAX_AGE یکی از تنظیمات مهم Django است که برای مدیریت اتصالات پایدار (Persistent Connections) به پایگاه داده استفاده می‌شود. این تنظیم مشخص می‌کند که یک اتصال به پایگاه داده برای چه مدت زمان زنده بماند و پس از آن بسته شود.

🔍 CONN_MAX_AGE چیست و چگونه عمل می‌کند؟

- مقدار CONN_MAX_AGE نشان‌دهنده مدت زمان (بر حسب ثانیه) است که یک اتصال به پایگاه داده در حالت باز باقی می‌ماند.
- اگر مقدار آن روی ۰ تنظیم شود، اتصال به پایگاه داده پس از هر درخواست بسته می‌شود (رفتار پیش‌فرض).
- اگر مقدار CONN_MAX_AGE روی `None` تنظیم شود، اتصال به پایگاه داده هرگز بسته نمی‌شود و دائماً زنده می‌ماند (تا زمانی که فرآیند Worker یا برنامه بسته شود).

⚙️ مقدار پیش‌فرض CONN_MAX_AGE

به صورت پیش‌فرض، مقدار CONN_MAX_AGE برابر با ۰ است. یعنی Django پس از پایان هر درخواست، اتصال به پایگاه داده را می‌بندد و برای درخواست جدید، اتصال دیگری باز می‌کند. این رفتار برای پروژه‌های کوچک یا آزمایشی مناسب است ولی در محیط تولید (Production) ممکن است باعث کاهش عملکرد شود.

✏️ نحوه تنظیم CONN_MAX_AGE

مقدار CONN_MAX_AGE در تنظیمات پایگاه داده تعریف می‌شود. مثال زیر نحوه استفاده از آن را نشان می‌دهد:

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql',
        'NAME': 'your_database',
        'USER': 'your_user',
        'PASSWORD': 'your_password',
        'HOST': 'your_host',
        'PORT': 'your_port',
        'CONN_MAX_AGE': 600,  # 600 seconds
    }
}

✅ چند سناریو برای تنظیم CONN_MAX_AGE

1. پروژه کوچک یا محیط توسعه
- سناریو: اگر پروژه شما تعداد کمی از درخواست‌ها را مدیریت می‌کند یا در حال توسعه هستید.
- مقدار پیشنهادی:

     'CONN_MAX_AGE': 0
     

- توضیح: اتصال پس از هر درخواست بسته می‌شود. این کار به شما کمک می‌کند که رفتار واقعی برنامه را در محیط توسعه مشاهده کنید.

2. پروژه با بار متوسط
- سناریو: اگر برنامه شما درخواست‌های متوسطی (نه کم، نه زیاد) دارد و پایگاه داده شما برای تعداد اتصالات زیاد محدودیت خاصی ندارد.
- مقدار پیشنهادی:

     'CONN_MAX_AGE': 300  # 5 minutes
     

- توضیح: این تنظیم باعث می‌شود که اتصالات برای چندین درخواست استفاده شوند و هزینه باز و بسته کردن اتصال کاهش یابد.

3. پروژه با بار زیاد (High Traffic)
- سناریو: اگر برنامه شما تعداد زیادی درخواست دارد و می‌خواهید عملکرد را بهینه کنید.
- مقدار پیشنهادی:

     'CONN_MAX_AGE': 600  # 10 minutes
     

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

4. پروژه‌های با درخواست‌های خیلی کم
- سناریو: اگر برنامه شما به ندرت به پایگاه داده متصل می‌شود (مثلاً به دلیل استفاده از کش یا تعامل کم با پایگاه داده).
- مقدار پیشنهادی:

     'CONN_MAX_AGE': 0  # each http request
     

- توضیح: نگه‌داشتن اتصال در این موارد منطقی نیست و بهتر است اتصال پس از هر درخواست بسته شود.

5. استفاده از Connection Pooling خارجی
- سناریو: اگر از ابزارهای خارجی مدیریت اتصال مانند pgbouncer (برای PostgreSQL) یا ProxySQL (برای MySQL) استفاده می‌کنید.
- مقدار پیشنهادی:

     'CONN_MAX_AGE': None
     

- توضیح: در این حالت، مدیریت اتصالات به ابزارهای خارجی سپرده شده است و Django نیازی به بستن اتصالات ندارد.

⚠️ نکات مهم:

1. مراقب تعداد اتصالات باشید:
اگر مقدار CONN_MAX_AGE را روی مقدار زیاد یا None تنظیم کنید، مطمئن شوید که سرور پایگاه داده شما می‌تواند تعداد زیادی اتصال همزمان را مدیریت کند. در غیر این صورت ممکن است با خطای "too many connections" مواجه شوید.

2. محیط production:
در محیط تولید، معمولاً مقدار CONN_MAX_AGE روی چند دقیقه (مثلاً ۵ تا ۱۰ دقیقه) تنظیم می‌شود تا عملکرد بهینه باشد و اتصالات مکرر ایجاد نشوند.

3. ابزارهای خارجی مدیریت اتصال:
اگر از Connection Pooling خارجی استفاده می‌کنید، مقدار CONN_MAX_AGE را روی None تنظیم کنید تا Django اتصال را مدیریت نکند.

conn_max_age

#database #django

@Syntax_fa

آشنایی با File and Directory Permissions در لینوکس یکبار برای همیشه

در لینوکس، هر فایل و دایرکتوری دارای سطوح دسترسی (Permissions) است که مشخص می‌کند چه کسی می‌تواند به فایل یا دایرکتوری دسترسی داشته باشد و چه کاری با آن انجام دهد. این سطوح دسترسی برای سه دسته اصلی تعریف می‌شوند:

1. Owner (مالک فایل یا دایرکتوری)
2. Group (گروهی که فایل یا دایرکتوری به آن تعلق دارد)
3. Others (سایر کاربران سیستم)

ساختار دسترسی‌ها

در ابتدای هر فایل یا دایرکتوری در خروجی دستور ls -l، سطح دسترسی آن به صورت زیر نمایش داده می‌شود:

drwxrwxrwx

این سطح دسترسی از 10 کاراکتر تشکیل شده است:

1. اولین کاراکتر: نوع فایل را مشخص می‌کند:
- - : فایل معمولی
- d : دایرکتوری
- l : لینک سمبلیک

2. 9 کاراکتر بعدی (سه گروه سه‌تایی): سطح دسترسی برای مالک، گروه و سایرین را نشان می‌دهد:
- r : اجازه خواندن (Read)
- w : اجازه نوشتن (Write)
- x : اجازه اجرا (Execute)

جدول باینری و مقادیر اعداد

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

| مقدار عددی | سطح دسترسی | باینری |

|------------|------------|---------|
| 7 | rwx | 111 |
| 6 | rw- | 110 |
| 5 | r-x | 101 |
| 4 | r-- | 100 |
| 3 | -wx | 011 |
| 2 | -w- | 010 |
| 1 | --x | 001 |
| 0 | --- | 000


مثال: chmod 777

دستور chmod برای تغییر سطح دسترسی فایل‌ها و دایرکتوری‌ها استفاده می‌شود. در مثال chmod 777:

- اولین عدد 7: سطح دسترسی مالک (Owner) است.
- دومین عدد 7: سطح دسترسی گروه (Group) است.
- سومین عدد 7: سطح دسترسی سایرین (Others) است.

سطح دسترسی هر عدد به صورت زیر تعریف می‌شود:

rwx | rwx | rwx

این به این معناست که:
- مالک: می‌تواند بخواند، بنویسد و اجرا کند.
- گروه: می‌تواند بخواند، بنویسد و اجرا کند.
- سایرین: می‌توانند بخوانند، بنویسند و اجرا کنند.

دسترسی‌های محدودتر

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

- chmod 644:
- مالک: rw- (خواندن و نوشتن)
- گروه: r-- (فقط خواندن)
- سایرین: r-- (فقط خواندن)

- chmod 755:
- مالک: rwx (خواندن، نوشتن و اجرا)
- گروه: r-x (خواندن و اجرا)
- سایرین: r-x (خواندن و اجرا)



- chmod +x:
دسترسی execute به مالک و گروه و دیگر کاربران

- chmod -r:
دسترسی read رو از مالک و گروه و دیگر کاربران میگیریم

نکته درباره دایرکتوری‌ها

برای دایرکتوری‌ها:
- r:
به کاربر اجازه می‌دهد محتویات دایرکتوری را مشاهده کند.
- w:
به کاربر اجازه می‌دهد فایل‌ها را حذف یا اضافه کند.
- x:
اجازه ورود به دایرکتوری را می‌دهد.

#file_and_directory_permission

@Syntax_fa

یه مدتی هست دارم سعی میکنم ترید کردن یاد بگیرم و پوزیشن های خیلی کوچیک باز میکنم و الان حدودا ۱۰ دلار تو اکانتم دارم. البته با ۱۵ دلار شروع کرده بودم :(
میخوام یه کانال سیگنال دهی بزنم و برعکس هرکاری خودم کردمو بذارم اونجا ملت استفاده کنن.

@normal_developer

مقاله زیر به ما آموزش میده چطور 1,000,000 رکورد دیتا رو در 4 ثانیه در PostgreSQL ذخیره کنیم!

https://www.timescale.com/learn/testing-postgres-ingest-insert-vs-batch-insert-vs-copy?ref=timescale.com

#postgresql
#database

source

@Syntax_fa

6 الگوی برتر معماری نرم‌افزار

معماری مونولیتیک (Monolithic Architecture)

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

این معماری برای پروژه‌های کوچک و تیم‌های کوچک مناسب است، اما برای پروژه‌های بزرگ‌تر، به دلیل وابستگی‌های زیاد میان اجزاء، مدیریت تغییرات بسیار دشوار می‌شود.


الگوی (Controller-Worker Pattern)

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

مناسب برای سیستم‌هایی است که بار پردازشی غیرهمزمان دارند، مانند پردازش صف‌ها (Queues) یا مدیریت درخواست‌های سنگین.

معماری میکروسرویس‌ها (Microservices Architecture)

معماری میکروسرویس‌ها برنامه را به سرویس‌های کوچک و مستقل تقسیم می‌کند که از طریق APIهای مشخص با یکدیگر ارتباط برقرار می‌کنند. هر سرویس مسئول یک قابلیت خاص از کسب‌وکار است و می‌تواند به‌طور مستقل توسعه، استقرار و مقیاس‌پذیری شود. این معماری انعطاف‌پذیری بیشتری فراهم می‌کند و امکان استفاده از فناوری‌های مختلف برای سرویس‌های مختلف را می‌دهد. اما مدیریت سرویس‌ها و ارتباط بین آن‌ها می‌تواند پیچیدگی‌هایی به همراه داشته باشد.

این معماری مناسب سازمان‌هایی است که نیاز به توسعه سریع و مقیاس‌پذیری خدمات دارند. اما نیازمند ابزارهای مناسب برای نظارت، هماهنگی و مدیریت ارتباطات میان سرویس‌ها است.


مدل (Model-View-Controller یا MVC)

الگوی MVC یک برنامه را به سه بخش مرتبط تقسیم می‌کند:
- مدل (Model): وظیفه مدیریت داده‌ها و منطق کسب‌وکار را دارد.
- نما (View): داده‌ها را به کاربر نمایش می‌دهد.
- کنترلر (Controller): ورودی کاربر را مدیریت کرده و با مدل تعامل دارد.

این جداسازی باعث سازماندهی بهتر کد می‌شود و مدیریت و مقیاس‌پذیری برنامه، به‌ویژه در توسعه وب، را آسان‌تر می‌کند.

این الگو در اکثر فریم‌ورک‌های وب مانند Django و Ruby on Rails استفاده می‌شود و برای پروژه‌هایی که نیاز به تعامل زیاد با کاربر دارند، ایده‌آل است.


معماری رویداد-محور (Event-Driven Architecture)

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

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


معماری لایه‌ای (Layered Architecture)

در معماری لایه‌ای، برنامه به لایه‌های مجزا با وظایف مشخص تقسیم می‌شود. لایه‌های رایج شامل موارد زیر هستند:
- لایه ارائه (Presentation Layer): وظیفه نمایش داده به کاربر.
- لایه منطق کسب‌وکار (Business Logic Layer): مدیریت منطق اصلی برنامه.
- لایه دسترسی به داده (Data Access Layer): مدیریت تعامل با پایگاه داده.

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

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

source

@Syntax_fa

دوستان اگه اپلیکیشن رو بصورت مونولیت مینیوسید، کار خوبی میکنید، اما aggregation pattern رو جدی بگیرید، کمک بزرگی میکنه به حفظ loosely coupled بودن ماژول و سرویس هاتون.

یه اشتباه رایجی که باعث میشه خیلی راحت همه چیز در هم تنیده و coupled بشه نیازهای بیزینسی ای هست که دیتای aggregate شده از چند domain مختلف رو میخواد از شما. تو حالت مونولیت خیلی ساده ست که شما در هر domain به دیتابیس یه domain دیگه درخواست بزنی و یا حتی تو interactor/service دیگه یه متد جدید تعریف کنی که دیتای مد نظر رو بده. که معمولا باعث در هم تنیده شدن و چاق شدن سرویس هاتون میشه.

بهتره سرویس یا همون interactorهاتون کارهای خیلی کوچیک و well-definedی رو انجام بدن و اگه نیازمندی های aggregationطور دارید، یه سری service دیگه بسازید که وابستگی خواهد داشت به سرویس های مختلف و دیتاهای raw رو میگیره و پردازش میکنه که دیتای نهایی رو آماده کنه.

بعضی وقت ها از طریق gateway هم ممکنه بتونید aggregate کنید. بعضی وقت ها ممکنه تو همون لایه دلیوری (کنترلر) تون بتونید دو تا سرویس رو فراخوانی کنید و کار رو در بیارید، گاهی هم پیچیده تر میشه و لازمه یه سرویس(interactor) بنویسید که کار aggregation رو انجام بده
https://learn.microsoft.com/en-us/azure/architecture/patterns/gateway-aggregation

باز خود aggregate کردن حالت های مختلفی داره، اینجا میتونید بیشتر بخونید در موردش
https://medium.com/geekculture/design-patterns-for-microservices-aggregation-pattern-1b8994516fa2

Source:
https://news.1rj.ru/str/gocasts

@Syntax_fa