مثال‌هایی از شکار و انحصارطلبی

1. مایکروسافت و نوآوری‌های Netscape: پایان مرورگر مستقل
در دهه ۹۰ میلادی، Netscape یکی از محبوب‌ترین مرورگرهای وب بود. این شرکت به نوعی پیشگام اینترنت مدرن به حساب می‌اومد و مایکروسافت که از محبوبیت و رشد سریع Netscape ترسیده بود، استراتژی تهاجمی خودش رو شروع کرد. 
مایکروسافت تصمیم گرفت مرورگر خودش به نام Internet Explorer رو به صورت رایگان همراه با ویندوز عرضه کنه. این حرکت باعث شد که کاربران به طور پیش‌فرض از Internet Explorer استفاده کنن و سهم بازار Netscape به شدت کاهش پیدا کنه. 
در نهایت، Netscape نتونست با این انحصارطلبی مبارزه کنه و ورشکست شد. این پرونده حتی به دادگاه ضدانحصار ایالات متحده کشیده شد، جایی که مشخص شد مایکروسافت عمداً از قدرت انحصاری ویندوز برای حذف رقبای مرورگر استفاده کرده. 

2. مایکروسافت و Skype: تصاحب و سقوط یک نوآوری
مایکروسافت در سال ۲۰۱۱ با مبلغ ۸.۵ میلیارد دلار Skype رو خریداری کرد. اسکایپ تا قبل از خرید یکی از محبوب‌ترین ابزارهای تماس ویدیویی و صوتی در جهان بود و به عنوان یک نوآوری مستقل می‌درخشید. اما بعد از خرید توسط مایکروسافت، مشکلات شروع شد: 
- مایکروسافت به جای توسعه و بهبود اسکایپ، تمرکز رو روی ادغام اون با محصولات خودش مثل ویندوز و Office گذاشت. 
- اسکایپ به مرور زمان از کارایی افتاد؛ مشکلات مربوط به کیفیت تماس و رابط کاربری گیج‌کننده باعث شد که بسیاری از کاربران به سرویس‌های رقیب مثل Zoom، WhatsApp، و Google Meet مهاجرت کنن. 
- نهایتاً، اسکایپ که یک‌زمانی یکه‌تاز بازار تماس‌های ویدیویی بود، به حاشیه رانده شد و تقریباً از فضای رقابت حذف شد. 

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

1. مایکروسافت و Nokia: شکست برنامه‌ریزی‌شده؟
   یکی از جنجالی‌ترین تصاحب‌های مایکروسافت، خرید بخش موبایل شرکت نوکیا در سال ۲۰۱۳ بود. نوکیا که زمانی بزرگترین تولیدکننده گوشی‌های موبایل در دنیا بود، به خاطر رقابت با سیستم‌عامل‌های اندروید و iOS دچار افت شد. مایکروسافت با وعده همکاری و توسعه، بخش موبایل نوکیا رو خرید و ادعا کرد که این خرید به زنده‌کردن نوکیا کمک می‌کنه. اما در واقعیت، این اتفاق به سقوط کامل نوکیا منجر شد:
   - مایکروسافت تصمیم گرفت که گوشی‌های نوکیا فقط با سیستم‌عامل Windows Phone عرضه بشن، که سهم بسیار کوچکی از بازار موبایل داشت. این تصمیم، نوکیا رو از رقابت با اندروید و iOS دور کرد.
   - سرمایه‌گذاری روی ویندوزفون شکست خورد و مایکروسافت خیلی زود این پروژه رو رها کرد.
   - در نهایت، بخش موبایل نوکیا تعطیل شد و هزاران نفر از کارکنانش بیکار شدن.

2. گوگل و DeepMind 
   گوگل وقتی DeepMind رو خرید، قول داد که این شرکت مستقل و متمرکز روی «هوش مصنوعی اخلاقی» باقی می‌مونه. اما حالا بیشتر کارای DeepMind روی پروژه‌هایی متمرکزه که به تبلیغات گوگل و سرویس‌های پول‌ساز این شرکت کمک می‌کنه. مثلاً پروژه‌های سلامت DeepMind به Google Health منتقل شدن، و حالا بیشتر از اینکه به اخلاق فکر کنن، به سوددهی فکر می‌کنن. 

3. آمازون و استارت‌آپ‌های خرده‌فروشی 
   آمازون یکی از بزرگترین شکارچی‌های استارت‌آپ‌های خرده‌فروشی هست. استراتژی‌شون؟ اول از یه استارت‌آپ حمایت می‌کنن، بعد یه نسخه مشابه از اون محصول رو ارزون‌تر تولید می‌کنن، و در نهایت یا اون استارت‌آپ رو می‌خرن یا ورشکسته‌ش می‌کنن. مثلاً استارت‌آپی مثل Diapers.com که تو فروش پوشک بچه موفق بود، اول تحت فشار قیمت‌های پایین آمازون قرار گرفت و در نهایت مجبور شد خودش رو بفروشه. 

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

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

@Syntax_fa

انحصارطلبی غول‌های فناوری: «ما حامی هستیم، اما فقط وقتی مال خودمون باشی!»

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

کافیه یه پروژه اوپن‌سورس یا یه استارت‌آپ کوچیک یه ذره رشد کنه و توجه‌ها رو به خودش جلب کنه. سریع یکی از این غول‌ها میاد، قربون‌صدقه میره و یه قلب بزرگ (❤️) پای پروژه می‌ذاره. اما این قلب زدن فقط یه راه مودبانه برای گفتن این جمله‌ست: "ما این رو می‌خریم!" و اگه نتونن بخرنش، وارد یه فاز تهاجمی‌تر میشن: نابودش کن!

فاز اول: قلب بزن، قربون‌صدقه برو
وقتی یه استارت‌آپ یا یه پروژه اوپن‌سورس داره رشد می‌کنه، اول از همه غول‌های فناوری میان و با لبخند ازش تعریف می‌کنن. مثلاً توییت می‌زنن:
"این پروژه واقعاً الهام‌بخشه. ما عاشق نوآوری هستیم و از این پروژه حمایت می‌کنیم!"
اما پشت این تعریف‌ها، مدیرای اجرایی و تیم‌های حقوقی شرکت دارن بررسی می‌کنن که چطور این پروژه رو تصاحب کنن. چون تو دنیای غول‌ها، کلمه «حمایت» معمولاً به معنی «ادغام در امپراتوری ما» است.

فاز دوم: چند ماه بعد، خبر میاد که:
"مایکروسافت/گوگل/آمازون این استارت‌آپ را با مبلغ X میلیون دلار خریداری کرد."
ظاهرش خیلی جذابه: استارت‌آپ حالا منابع بیشتری داره و می‌تونه سریع‌تر رشد کنه. ولی در واقعیت، این خرید بیشتر شبیه یه «عملیات خفه کردن» برای کنترل یا حذف رقابت در بازار هست.

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

@Syntax_fa

استراتژی Deployment در Kubernetes چیست؟

برای درک مفهوم **استراتژی Deployment در Kubernetes، ابتدا باید دو معنای ممکن "deployment" در محیط Kubernetes را توضیح دهیم:

1. deployment**
   به فرآیند نصب یک نسخه جدید از یک اپلیکیشن یا workload روی pods در Kubernetes اشاره دارد.
2. Deployment
   (با D بزرگ)، یک Kubernetes object است که دارای فایل تنظیمات YAML مخصوص به خود می‌باشد و به شما این امکان را می‌دهد که تعیین کنید:
   - فرآیند deployment چگونه باید انجام شود،
   - دقیقاً چه چیزی باید deploy شود،
   - و همچنین چگونه درخواست‌ها به اپلیکیشن جدید هدایت شوند.

استراتژی deployment تعیین می‌کند که چگونه pods باید به نسخه جدید اپلیکیشن به‌روزرسانی شوند. به‌عنوان مثال، یک گزینه این است که تمامی pods حذف شوند و با نسخه جدید جایگزین شوند؛ این روش باعث downtime می‌شود. اما گزینه‌های پیشرفته‌تری نیز وجود دارند که اپلیکیشن را به‌صورت تدریجی با کمترین اختلال در خدمات به‌روزرسانی می‌کنند.

1. Recreate Deployment
   این روش یک فرآیند همه یا هیچ است که اپلیکیشن را فوراً به‌روزرسانی می‌کند، اما با مقداری downtime همراه است.

- در این استراتژی، pods موجود حذف می‌شوند و نسخه جدید جایگزین آن‌ها می‌شود.
- این روش باعث می‌شود که از زمان خاموش شدن نسخه قدیمی تا شروع به کار نسخه جدید، اپلیکیشن downtime داشته باشد.
- موارد استفاده مناسب:
- محیط‌های توسعه (development environments).
- زمانی که کاربران ترجیح می‌دهند یک دوره کوتاه downtime به جای کاهش عملکرد یا خطاهای طولانی‌مدت (در rolling deployment) داشته باشند.
- زمانی که دلایل فنی اجازه اجرای دو نسخه همزمان از یک اپلیکیشن را نمی‌دهند(برای مثال statefull بودن برنامه).

1. Rolling Deployment
   در این استراتژی، نسخه جدید اپلیکیشن به‌صورت تدریجی روی pods مستقر می‌شود.
   - مزایا:
   - امکان بازگشت (rollback) آسان‌تر.
   - ریسک کمتری نسبت به روش Recreate دارد.
   - نسبتا راحت پیاده‌سازی می‌شود.
   - معایب:
   - ممکن است کند باشد.
   - در صورت بروز مشکل، بازگشت به نسخه قبلی دشوارتر است.
   - اجرای همزمان چند نسخه از اپلیکیشن ممکن است برای اپلیکیشن‌های قدیمی مشکل‌ساز باشد.

2. Blue/Green Deployment (Red/Black Deployment)
   این استراتژی به شما امکان می‌دهد که نسخه جدید اپلیکیشن را بدون downtime مستقر کنید.

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

1. Canary Deployment
   این استراتژی به شما امکان می‌دهد نسخه جدید اپلیکیشن را روی گروه کوچکی از کاربران واقعی آزمایش کنید.

- به صورت تدریجی نسخه جدید در cluster مستقر شده و روی مقدار کمی از ترافیک زنده آزمایش می‌شود.
- پس از اطمینان از عملکرد صحیح، نسخه جدید به طور کامل جایگزین نسخه قبلی می‌شود.
- مزایا:
- ریسک کمتر برای انتشار تغییرات بزرگ یا ویژگی‌های آزمایشی.
- امکان rollout تدریجی.
- معایب:
- نیاز به اجرای همزمان چند نسخه از اپلیکیشن.
- نیاز به مکانیزم هوشمند برای هدایت بخشی از ترافیک به نسخه جدید.

1. A/B Testing

در Kubernetes، A/B Testing نوعی از canary deployment است که ترافیک را بر اساس پارامترهای خاص (مانند کوکی‌ها یا user agents) بین نسخه‌های مختلف اپلیکیشن توزیع می‌کند.

- این روش برای آزمایش گزینه‌های مختلف یک ویژگی جدید و انتخاب نسخه‌ای که کاربران بیشتر می‌پسندند، مناسب است.
- تفاوت اصلی با canary deployment در نحوه توزیع کاربران است.

1. Shadow Deployment
   در این روش، نسخه جدید اپلیکیشن روی production workloads آزمایش می‌شود، اما بدون اینکه کاربران نهایی متوجه شوند.

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

نکته:
توجه داشته باشید که فقط دو استراتژی Recreate و Rolling به‌صورت پیش‌فرض توسط Kubernetes Deployment object پشتیبانی می‌شوند. سایر استراتژی‌ها نیازمند سفارشی‌سازی یا استفاده از ابزارهای تخصصی هستند.

source

#deployment_strategy

@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

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