کمی دور از انتظار باشه این رو به عنوان کسی دارم میگم که سالها ظهور و ناپدید شدن تکنولوژی ها و نوع تفکر قالب بر نرم افزار رو لمس کردم و در این فضا کار کردم به عنوان کسی که وقتی #ویژوال بیسیک کار میکردم فکر نمیکردم روزی از بازار حذف بشه یا فکر نمیکردم دات نت با یک تغییر در ساختار و رفتن سراغ #netcore بتونه با جاوا رقابت کنه و باز هم برام قابل تعریف نبود که زبان تازه به دنیا اومده ای مثل #گولنگ و #راست چنین با اقتدار قد علم کنن و مرزهای پرفورمنس رو به لرزه دربیارن و شاید تصور اینکه روزی در دنیای وب رقیبهایی به این قدرت رو برای #php متصور بشم سخت بود اما امروز با توجه به تمام تغیرات چه در نگرش به نرم افزار و معماری نرم افزار و همچنین پیش اومدن هوش مصنوعی در این حوزه به ناچار باید بگم دنیای #شی گرایی و #معماریهای شی گرا کم کم دارن کوله بارشون رو میبندن و زبانهای شی گرا باید جاشون رو به زبانهای جوانتر مثل همین #گولنگ و #راست بدن حرف من کنار رفتن زبانهای جاوا یا سی شارپ نیست دوستان موضوع کم رنگ شدن و قدرت گرفتن تفکر جدید هست تغییر نگرش زمانبر و طولانی مدت خواهد بود ولی #ساده سازی نوع #تفکر در برنامه نویسی و گذار از روش های سنتی و معماریهای سنتی در حال انجامه برای همین شما اسم #ورتیکال یا معماریهای مدرن دیگه رو میشنوید #مراقب جا موندن از قطار پر سرعت تغییرات باشید

Source

@Syntax_fa

شما در این ویدئو یک CPU آیفون را در زیر میکروسکوپ در کنار یک تار مو بعنوان مقایسه اندازه آن مشاهده می‌کنید.

@Syntax_fa

تست Canary: راز پشت پرده تغییرات گوگل

چند وقت پیش داشتم ایمیل‌هایم را در گوگل چک می‌کردم که یک ویژگی جدید توجه من را جلب کرد؛ دکمه‌ای مخصوص پرسش از هوش مصنوعی درباره‌ی محتوای ایمیل‌ها. فکر کردم این یک تغییر جذاب است و سری به بقیه ایمیل‌هایم زدم تا از این فیچر استفاده کنم. اما جالب بود که این ویژگی فقط در یک ایمیل فعال شده بود! چرا همه کاربران این ویژگی را ندارند؟ مگر این همان گوگل نیست که وقتی چیزی اضافه می‌کند برای همه فعال می‌شود؟

با کمی تحقیق و کنجکاوی، به یک واژه رسیدم:
Canary Test

چرا تست Canary؟
تصور کنید گوگل می‌خواهد ویژگی جدیدی را به سرویس ایمیل خود اضافه کند. اگر این ویژگی به‌درستی کار نکند، ممکن است کل سیستم ایمیل دچار مشکل شود. اما به کمک Canary Test، ابتدا این تغییرات را برای گروه کوچکی از کاربران فعال می‌کنند. اگر همه‌چیز درست کار کرد، این تغییر را برای کاربران بیشتری اجرا می‌کنند؛ و اگر مشکلی رخ داد، به‌سرعت به نسخه قبلی برمی‌گردند، بدون این‌که کسی متوجه شود.

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

گوگل، فیس‌بوک و سایر غول‌ها چطور از Canary Test استفاده می‌کنند؟
در این روش، غول‌های فناوری مثل گوگل و فیس‌بوک ابتدا تغییرات را به درصد کوچکی از کاربران عرضه می‌کنند. این کاربران به‌عنوان "قناری‌های" سیستم انتخاب می‌شوند تا در صورت شناسایی خطر، باقی کاربران در امان بمانند. اگر همه‌چیز خوب پیش رفت، تغییرات به همه عرضه می‌شود؛ و اگر نه، به‌راحتی تغییرات را متوقف می‌کنند.

پس اگر روزی دیدید که شما یک قابلیت خاص در یک اپلیکیشن دارید و دوستانتان نه، بدانید شاید شما هم یکی از «قناری‌ها»ی سیستم باشید! 🐤

Source

@Syntax_fa

ادعای هک اطلاعات یکونیم میلیون کاربران بلو بانک.
دیگه فکر کنم برای ملت فرقی نمیکنه چون کل ایران اپن سورسه.

https://youtu.be/iaMeC798mdI?si=uN3oCDuAuIHUjRY6

@Syntax_fa

گفتگو شنیدنی GoCasts با مهندس کیانوش مختاریان، مهندس نرم افزار، رهبر فنی سابق در گوگل. 

https://gocasts.ir/talk-with-kain

@Syntax_fa

در برنامه‌نویسی، اصطلاح "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