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

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

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

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

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

@normal_developer

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

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

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

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

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

#idiomatic

@Syntax_fa

برنامه‌نویس‌های ادایی: قهرمانان سلفی‌گیر! ?

برنامه‌نویس‌های ادایی، آن دسته از افراد در دنیای فناوری هستند که بیشتر از اینکه به کدنویسی بپردازند، به گرفتن سلفی‌های خفن با لپ‌تاپ و قهوه‌شان مشغول‌اند. بیایید نگاهی به دنیای رنگارنگ آن‌ها بندازیم!

سلفی‌های جذاب با لپ‌تاپ

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

"نگاه کن من دارم کد میزنم"
در واقع، آن‌ها فقط در حال چک کردن فید اینستاگرامشان هستند!

بحث درباره clean architecture همه جا!
همیشه همراه خود کتاب های برنامه نویسی خفن را حمل میکنند حتی در کافه و مهمانی ها!
تا بحث درباره برنامه نویسی شود، کتاب های که درباره clean architecture و ddd و ... خوانده اند صحبت میکنند اما هنوز نمی‌توانند یک پروژه todo را با ساختار مناسب پیاده سازی کنند!

میز کار به سبک هنری ?

میز کار این برنامه‌نویس‌ها مثل یک گالری هنری است؛ قهوه‌ساز، کتاب‌های مهندسی نرم‌افزار، و چندین ماگ با نوشته‌های خنده‌دار. آن‌ها با افتخار به شما نشان می‌دهند که "این کتاب رو تازه خریدم!" در حالی که هیچ‌وقت حتی یک صفحه از آن را نخوانده‌اند. گویی که داشتن کتاب‌های مهندسی نرم‌افزار به‌عنوان یک اکسسوری مهم است!

پوشش‌های خاص با تی‌شرت‌های برنامه‌نویسی ?

این افراد معمولاً تی‌شرت‌های با طرح‌های مرتبط با برنامه‌نویسی می‌پوشند، مثل "Code is my cardio" یا "I'm silently correcting your code". گویی لباسشان بهترین بیانیه‌ی حرفه‌ای آن‌هاست!

رویدادهای کافه‌ای ☕️

برنامه‌نویس‌های ادایی معمولاً در کافه‌ها جمع می‌شوند تا نمیدونم واقعا چیکار کنن ☹️

بحث‌های پرشور درباره buzzword ها

وقتی دو برنامه‌نویس ادایی با هم ملاقات می‌کنند، یک بحث پرشور درباره جدیدترین فریم‌ورک‌ها یا زبان‌های برنامه‌نویسی شروع می‌شود. در واقع، این بحث‌ها بیشتر شبیه به مسابقه‌ی خودستایی است تا تبادل دانش واقعی!
اوه از همه بدتر وقتی با یه برنامه نویس ادایی صحبت میکنید کلمات و اصطلاحاتی رو بکار میبره که خداهم تاحالا نشنیده!
بازورد چیه؟ #buzzword

مبادا مثل آدم کد بزنی!

کد های یک برنامه نویس ادایی رو فقط یک برنامه نویس ادایی دیگه میفهمه!
تا جای ممکن سعی میکنن کدی بنویسن که پیچیده و غیرقابل فهم باشه.
چیزی که فکر میکنن:
پشمام چه کدی زدی?
ولی واقعیت موضوع:
این چه کدشریه دیگه?

#fun

@Syntax_fa

نحوه احراز هویت با OAuth

OAuth
یک پروتکل احراز هویت و مجوز است که به کاربران اجازه می‌دهد بدون نیاز به اشتراک‌گذاری اطلاعات ورود خود، به وب‌سایت‌ها و اپلیکیشن‌های مختلف دسترسی پیدا کنند. این پروتکل معمولاً در سه مرحله اصلی کار می‌کند:

1. درخواست مجوز: کاربر به اپلیکیشن شما اجازه می‌دهد به حساب کاربری‌اش در سرویس‌دهنده (مثل گوگل) دسترسی پیدا کند.
2. دریافت توکن دسترسی: پس از تأیید مجوز کاربر، اپلیکیشن شما یک توکن دسترسی (Access Token) دریافت می‌کند.
3. دسترسی به منابع: با استفاده از توکن دسترسی، اپلیکیشن شما می‌تواند به منابع کاربر دسترسی پیدا کند.
   مراحل لاگین با اکانت گوگل
   1. ثبت‌نام اپلیکیشن در کنسول گوگل
   ابتدا باید اپلیکیشن خود را در https://console.cloud.google.com/. در اینجا ثبت کنید:

- یک پروژه جدید ایجاد کنید.
- OAuth 2.0 client ID ایجاد کنید.
- URL کال بک (Redirect URI) را مشخص کنید.

پس از این مراحل، یک Client ID و Client Secret دریافت خواهید کرد.

2. درخواست مجوز

هنگامی که کاربر روی دکمه "ورود با گوگل" کلیک می‌کند، شما باید او را به URL زیر هدایت کنید:

https://accounts.google.com/o/oauth2/v2/auth?client\_id=YOUR\_CLIENT\_ID&redirect\_uri=YOUR\_REDIRECT\_URI&response\_type=code&scope=email%20profile

در اینجا:

- YOUR_CLIENT_ID: شناسه کلاینت شما
- YOUR_REDIRECT_URI: URL کال بک شما
- scope: اطلاعاتی که می‌خواهید از کاربر بگیرید (مثل ایمیل و پروفایل)

3. دریافت کد تأیید

پس از اینکه کاربر مجوز را تأیید کرد، گوگل کاربر را به URL کال بک شما باز می‌گرداند و یک پارامتر code به همراه خواهد داشت.

4. تبادل کد برای توکن دسترسی

شما باید یک درخواست POST به URL زیر ارسال کنید تا کد را برای توکن دسترسی مبادله کنید:

POST https://oauth2.googleapis.com/token

بدنه درخواست باید شامل موارد زیر باشد:

{ "code": "CODE\_RECEIVED\_FROM\_GOOGLE", "client\_id": "YOUR\_CLIENT\_ID", "client\_secret": "YOUR\_CLIENT\_SECRET", "redirect\_uri": "YOUR\_REDIRECT\_URI", "grant\_type": "authorization\_code" }

5. دریافت توکن دسترسی

اگر درخواست موفق باشد، شما یک پاسخ JSON دریافت می‌کنید که شامل access_token و اطلاعات دیگر است.

6. احراز هویت و دسترسی به اطلاعات کاربر

با استفاده از access\_token، می‌توانید اطلاعات کاربر را از API گوگل دریافت کنید. برای مثال:

GET https://www.googleapis.com/oauth2/v2/userinfo Authorization: Bearer ACCESS\_TOKEN

7. وریفای توکن

برای اطمینان از صحت توکن، می‌توانید توکن را به یکی از انتهای API گوگل ارسال کنید تا اطلاعات مربوط به توکن و اعتبار آن را دریافت کنید.

#oauth

@Syntax_fa

چند نکته درباره وب سوکت و توضیح ساده برای درک بهتر

فرآیند ارتباط وب‌سوکت

1. شروع با HTTP/HTTPS:
   - کلاینت ابتدا یک درخواست HTTP به سرور می‌فرستد. این درخواست شامل هدرهای خاصی است که نشان‌دهنده تمایل به ارتقاء ارتباط به وب‌سوکت است. این هدرها شامل موارد زیر هستند:
   - Upgrade: websocket
   - Connection: Upgrade

2. ارتقاء به وب‌سوکت:
   - سرور درخواست را دریافت کرده و بررسی می‌کند. اگر شرایط درست باشد، با یک پاسخ خاص به کلاینت، ارتباط را به وب‌سوکت ارتقاء می‌دهد. این پاسخ شامل وضعیت 101 Switching Protocols است.

3. استفاده از ws:// و wss://:
   - پس از ارتقاء، ارتباط به‌صورت دائمی و دوطرفه برقرار می‌شود.
   - ws://
   نشان‌دهنده استفاده از پروتکل وب‌سوکت بر روی HTTP است.
   - wss://
   نشان‌دهنده استفاده از پروتکل وب‌سوکت بر روی HTTPS است (که رمزنگاری شده است).
   چرا ws:// استفاده می‌شود؟

- ws://localhost:8080
- این URL نشان می‌دهد که ارتباط نهایی به‌صورت وب‌سوکت انجام می‌شود.

نکته:
در HTTP/2، مکانیزم آپگرید به وب‌سوکت از طریق هدرهای HTTP/1.1 استفاده نمی‌شود. HTTP/2 به صورت ذاتی از این روش پشتیبانی نمی‌کند. برای ارتباط وب‌سوکت در HTTP/2، معمولاً از HTTP/1.1 برای ایجاد و ارتقاء ارتباط استفاده می‌شود یا از روش‌های دیگری برای مدیریت ارتباطات بلادرنگ بهره می‌گیرند.

روش‌های دیگه برای مدیریت ارتباطات بلادرنگ:
1. Server-Sent Events (SSE):
- یک ارتباط یک‌طرفه است که سرور می‌تواند به‌طور پیوسته داده‌ها را به کلاینت ارسال کند.
- مناسب برای برنامه‌هایی که نیاز به ارسال داده‌های بلادرنگ از سرور به کلاینت دارند.

1. Long Polling:
   - کلاینت یک درخواست HTTP ارسال می‌کند و سرور تا زمانی که داده‌ای برای ارسال وجود ندارد، پاسخ را معلق نگه می‌دارد(یک تایم اوت مشخص هم دارد مثلا 20 ثانیه)
   - پس از ارسال داده، کلاینت بلافاصله یک درخواست جدید ارسال می‌کند.

2. HTTP/2 Streams:
   - استفاده از قابلیت چندپخشی و استریم‌های همزمان در HTTP/2 برای ارسال و دریافت داده‌های بلادرنگ.

3. gRPC:
   - یک فریم‌ورک RPC بر پایه HTTP/2 که از ارتباطات بلادرنگ و استریمینگ پشتیبانی می‌کند.

چرا نیاز به درخواست HTTP اولیه است؟

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

مثال در گولنگ:

```
package main

import (
"fmt"
"net/http"
"github.com/gorilla/websocket"
)

var upgrader = websocket.Upgrader{
CheckOrigin: func(r *http.Request) bool {
// checking conditions
return true
},
}

func handleConnections(w http.ResponseWriter, r *http.Request) {
// upgrade http request to websocket
ws, err := upgrader.Upgrade(w, r, nil)
if err != nil {
fmt.Println(err)
return
}
defer ws.Close()

// messages
for {
messageType, msg, err := ws.ReadMessage()
if err != nil {
fmt.Println(err)
break
}
fmt.Printf("Received: %s\n", msg)

}
}

func main() {
http.HandleFunc("/", handleConnections)
fmt.Println("Server started on :8080")
err := http.ListenAndServe(":8080", nil)
if err != nil {
fmt.Println("Error starting server:", err)
}
}
```

#websocket

@Syntax_fa