❇️ رویداد بزرگ Ignite 2024 در حال برگزاریه

طبق انتظار و مشابه ۳ سال گذشته، تقریبا همه موضوعات به نحوی با AI گره خورده!

یکی از جالب‌ترین بخش‌هاش Fabric Databases است. مایکروسافت سال پیش Fabric رو عمومی کرد و حالا با اضافه کردن دیتابیس‌های عملیاتی/تراکنشی، گام بزرگی برای تکمیل زنجیره تولید و عرضه‌ی عملیات تا تحلیل داده برداشت. چیزی که ساخته یه سیستم همه‌فن‌حریف تو حوزه داده است، از بنیان با AI یکپارچه شده و از طراحی جداول و کوئری‌نویسی AI در کنار توسعه‌دهنده است، تا ارائه محصول و ارائه AI روی دیتایی که توی اون دیتابیس ذخیره می‌شه. پرفرمنس و ایندکس و دسترس‌پذیری (HA) دغدغه و مسئله توسعه‌دهنده نیست... به بیان ساده‌تر داره کاری می‌کنه که AI در نرم‌افزارها مثل log نوشتن توی نرم‌افزار ساده بشه و نیاز به دانش خاص نداشته باشه!

به دلیل محدودیت تلگرام، ادامه در کامنت ↙️

شاید برای شما هم پیش اومده باشه که با خودتون فکر کنید «تا کِی باید توی شرکت فعلی یا پوزیشن فعلی بمونم که درگیر رخوت و رکود نشم؟!»

شاید به تغییر شغل هر چند سال یکبار فکر کرده باشید...

نه «موندن» نه «تغییر دادن» شغل در یک شرکت، به تنهایی ضامن «حال خوب» داشتن در کار نیست... بلکه اینکه «کجا» «چجوری» «چه کاری» رو با «چه رویکردی» انجام بدیمه که می‌تونه کمک کنه به داشتن حس پویایی، حس مولد بودن و نهایتا «حالِ خوب»

حالا Larry Osterman بعد از ۴۰ سال و ۴ ماه کار کردن توی مایکروسافت در قامت Principal Software Design Engineer در ویدیوهای کوتاه داره تجربیات و خاطراتش رو بیان می‌کنه، از چالش‌های فنی یا خاطرات بامزه و خنده‌دار.

خلاصه اینکه، هر چند سال که از شروع کارمون گذشته، همیشه به این فکر کنیم، «کجا» «چی‌کار» کنیم که بعد از ۴۰ سال تجربه و کار، «حال خوب» داشته باشیم و حس رخوت و خسران نکنیم... مهم نیست یک‌جا بمونیم یا گاهی تغییر شغل یا تغییر کشور داده باشیم...

داشتن پلن و career path خیلی مهمه. می‌ارزه براش بخونیم، مشورت بگیریم و دغدغه‌اش رو داشته باشیم.

دوست داشتید در مورد career path نظرتون رو گید تا گپ بزنیم 😊

📽 ویدیو اول از سری آموزشی NET Aspire.

سلام
ویدیو اول از سری آموزشی NET Aspire. که مقدمه و معرفی است روی یوتیوب قرار گرفت.
احتمالا این سری ۳ قسمت داره که قسمت اول، مقدمه، معرفی امکانات و کاربرد و قابلیت‌های Aspire است و ویدیو دوم، گام‌به‌گام به پروژه جدید و پروژه موجود اضافه خواهیم کرد. و ویدیو سوم هم نوشتن component و integration جدید رو خواهیم دید.

📽 لینک یوتیوب

امیدوارم زودتر ویدیو دوم رو آماده و منتشر کنم 🏃‍♂️
♻️🌱 امیدوارم مفید باشه و اگر دوست داشتید به دوستانتون هم معرفی کنید 😊

💬 ✏️ مصاحبه با معمار ارشد کاتلین در مورد آینده زبان و موقعیتش نسبت به جاوا

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

خلاصه صحبتش در مورد ارتباط کاتلین با جاوا و آینده‌ی این مسیره! چالش‌هاشون در توسعه کاتلین و حتی کاستی‌هاش! داستان‌های thread و انتظارشون برای Loom. طبق آمارشون حدود ۴۰ درصد توسعه‌دهنده‌ها از کاتلین برای بکند سمت سرور استفاده می‌کنن. اینکه چرا هنوز LSP ندادن تا ادیتورهایی مثل VS Code از LSP رسمی برای توسعه و دیباگ و تحلیل کد کاتلین استفاده کنن و...

🔗 لینک مطلب

مصاحبه‌های این چنینی کلن جالب و البته خیلی آموزنده هستن... خصوصا آدمایی در این سطح مثل:
Anders Hejlsberg (Delphi, C#, TypeScript)
Guido van Rossum (Python)
Linus Torvalds (Linux, git)
Robert Griesemer (Go, V8)
Andrew Kelley (zig)

شاید توی مسیر کاری ما توسعه زبان برنامه‌نویسی یا چیزی در اون حد لایه‌پایینی نباشه؛ ولی عموم مصاحبه‌ها در مورد مسائلیه که آدم‌هایی در سطح ما باهاشون سر و کار دارن، و کلی یادگیری از جنس «نوع و زاویه نگاه و دغدغه» داره!
نظرتون چیه؟ 🤔😉

📊 خلاصه گزارش وضعیت پلتفرم انجینیرینگ ۲۰۲۴

سلام
یادتونه در مورد پلتفرم انجینیرینگ گفته بودم توی پادکست اول؟ حالا یه گزارش جذاب از وضعیت پلتفرم انجینیرینگ تو ۲۰۲۴ منتشر شده که نکات مهمش رو براتون خلاصه کردم (بعدا توی کامنت اضافه خواهم کرد):

۱) هایپ پلتفرم انجینیرینگ همچنان داغه! 🔥

امسال گارتنر تو بیش از ۱۰ تا از گزارش‌های هایپ‌سایکل خودش بهش اشاره کرده و حتی یه هایپ‌سایکل اختصاصی هم براش درآورده!
فرصت‌های مرتبط تو لینکدین هم رشد چشمگیری داشته

۲) وضعیت AI تو پلتفرم انجینیرینگ 🤖

با اینکه ۴۰٪ وبینارها درباره AI بودن
فقط ۱۵٪ تیم‌ها دارن واقعاً ازش استفاده می‌کنن!!

۳) وضعیت اندازه‌گیری و متریک‌ها 📈

نکته عجیب: ۴۵٪ تیم‌ها اصلاً متریک‌های خودشون رو اندازه نمی‌گیرن!
۲۷٪ نمی‌دونن بعد از پیاده‌سازی پلتفرم، متریک‌هاشون بهتر شده یا نه

💡 نتیجه‌گیری: پلتفرم انجینیرینگ همچنان در حال رشده و با اینکه یه حوزه نسبتاً جدیده، داره توسط افراد باتجربه هدایت میشه. اختلاف حقوق معنادار با دِوآپس نشون میده که بازار کار خوبی داره!
امیدوارم این اطلاعات به دردتون بخوره! 🚀

❇️ آمار و ارقام بیشتر رو توی کامنت اضافه خواهم کرد

🚀🚀 تست رفتارها و خطاهای API به سادگی، با Dev Proxy
—————————————————————————
تا حالا شده موقع توسعه یه اپلیکیشن، API ای که ازش استفاده‌ می‌کردید یهو به مشکل بخوره؟ مثلاً سرور پاسخ نده، تأخیر داشته باشه، یا با خطای محدودیت نرخ (Rate Limit) روبه‌رو بشین؟ خب، اگه یه اپلیکیشن اصولی می‌سازین، باید بدونین که این اتفاقات واقعی‌ان و ممکنه تجربه کاربر رو خراب کنن.

برای اینکه این مشکلات رو قبل از اینکه وارد دنیای واقعی بشین شبیه‌سازی کنین، یه ابزار خیلی خوب به اسم Dev Proxy موجود داره برای شبیه‌سازی این مشکلات. با Dev Proxy می‌تونین رفتارهای مختلف رو شبیه‌سازی کنین و مطمئن بشین اپلیکیشن‌تون تو هر شرایطی سر بلند بیرون میاد.

♻️ کاربرد Dev Proxy: کجا به درد می‌خوره؟

در واقع Dev Proxy دقیقاً یه پروکسی شبکه است که بین اپلیکیشن شما و API قرار می‌گیره. وظیفه‌اش شبیه‌سازی شرایطیه که ممکنه یه API تو دنیای واقعی تجربه کنه. مثل:

- ایجاد تأخیر (Latency): شبیه‌سازی شرایطی که سرور کند پاسخ می‌ده.

- خطاهای HTTP: مثل خطاهای 500 (Internal Server Error)، یا 404 (Not Found) یا حتی 429 (Too Many Requests).

- خطای Rate Limiting: مثلا وقتی که اپلیکیشن شما API رو صدا می‌کنه ولی با خطای محدودیت نرخ درخواست‌ها روبرو می‌شه چی‌ می‌شه.

- حذف داده‌ها یا پاسخ‌های ناقص از طرف API

⚙️ مثال عملی:
فرض کنین یه اپلیکیشن مالی نوشتین که نرخ تبدیل ارزها رو از یه API می‌گیره. حالا، اگه API به هر دلیلی کند بشه یا خطا بده، اپلیکیشن شما نباید متوقف بشه یا داده اشتباه نشون بده. با Dev Proxy می‌تونید این سناریوها رو شبیه‌سازی کنید و رفتار اپلیکیشن رو در این شرایط بسنجین.

یکی از خوبی‌های Dev Proxy اینه که به زبان یا تکنولوژی خاصی وابسته نیست. عملا یه ابزار جمع‌وجوره که روی مک، لینوکس یا ویندوز نصب می‌شه و شما می‌تونید ازش برای هر اپلیکیشنی که با API از نوع HTTP REST یا gRPC کار می‌کنه، استفاده کنید. فرقی هم نداره اپلیکیشن‌ دات‌نت، جاوا، پایتون، یا جاوااسکریپت باشه.

من قدیم از Mountebank استفاده می‌کردم ولی از ده سال پیش دیگه آپدیت نداد، بعدش postman mock server و مدتی از WireMock و یک سالی می‌شه که اکثرا از Dev Proxy استفاده می‌کنم، تقریبا از زمانی که دیگه کم‌کم به ابزار خوبی تبدیل شد، با اینکه هنوز به نسخه ۱ نرسیده ولی اکثر نیازها رو برای توسعه و تست برآورده می‌کنه و به راحتی توی CI/CD قرار می‌گیره.

گیت‌هاب
مستندات رسمی

نصب روی ویندوز:
winget install Microsoft.DevProxy
نصب رو مک:
brew tap microsoft/dev-proxy
brew install dev-proxy
نصب روی لینوکس:
bash -c "$(curl -sL https://aka.ms/devproxy/setup.sh)"


مثال:
برای شبیه سازی تاخیر ۲ ثانیه‌ای در پاسخ دادن:
dev-proxy --latency 2000

برای برگردوندن خطای ۵۰۰
dev-proxy --error 500

✨ نظرتون چیه؟ بعد از انتشار ویدیو aspire بریم سراغ ویدیو آموزشی براش؟

✨ دلایل عدم موفقیت استفاده از IaC توی شرکت‌ها چیه؟

چند روز پیش گزارش خوب Stacked Up 2024 منتشر شد. سعی کردم تا نکات مهمش رو اینجا بنویسم و کمی در مورد تفاوت Infrastructure as Code و Infrastructure from Code (IaC و IfC) هم توضیح بدم

لینک مطلب من
گزارش اصلی Stacked Up 2024

🤔 تا حالا براتون سوال شده که چرا بعضی شرکت‌ها توی مصاحبه فنی‌شون اینقدر روی مسایل ساختمان‌داده و الگوریتم تکیه دارن؟ (ادایی‌ها رو نمی‌گم 😁 درست و حسابی‌ها رو می‌گم)

دیروز یه خبر توی فیدها اومد مبنی بر مشکل کُندی NuGet و ماجرای حل کردنش توی دات‌نت ۹. شاید بگید به من چه؟! من مصرف‌کننده هستم و خوب و بدش پای مایکروسافته. اصلنشم من احساس کندی نکردم...

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

اگر دوست داشتید بخونید و نظرتون رو بگید

لینک مطلب

پی‌نوشت: قابلیت instant view تلگرام روی دسکتاپ و iOS برای متون راست‌به چپ باگ داره، قبلا توی گیت‌هاب طرح کردم و تعدادیش برطرف شد، پیگیر هستم تا بقیه‌اش هم حل بشه. شاید و شاید به زودی در قالب خبرنامه برخی مطالب و لینک‌های مفید روزانه رو هم داشته باشیم...

🚀📽 برای اجرای یک میلیون تسک به صورت هم‌زمان چقدر حافظه نیاز داریم؟ بنچمارک دات‌نت ۹ با سایر تکنولوژی‌های رایج

دیشب David Folwler یک توییت زد و لینک یک بنچمارک رو اشتراک گذاشت که امروز توی توییتر و لینکدین زیاد دیدمش، برای همین طی یک ویدیو کوتاه ۱۰ دقیقه‌ای توضیحش دادم. و تفاوت AOT و JIT رو به زبان ساده مرور کردم.
امیدوارم مفید باشه 😊


🔗 لینک توییت
🔗 لینک بنچمارک
🔗 گیت‌هاب مباحثه در مورد بهبود Async
🔗 مستندات رسمی محدودیت‌های AOT

⚙️✨ شاید براتون پیش اومده باشه که نیاز پیدا کرده باشید تا بدون دغدغه یه REST API رو صدا کنید، جواب دلخواهتون رو بگیرید و کارتون رو پیش ببرید.

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

مفهوم JSON Fake Server چیز جدیدی نیست، نمونه‌های متعددی هم داره که برای توسعه تست یا نمونه‌سازی (Prototyping) استفاده می‌شن. چیزی که بدون نیاز به تنظیمات پیچیده، بلافاصله آماده استفاده باشه.

📃 معرفی اولیه یک ابزار:

- بدون نیاز به تعریف نوع‌داده یا مسیرها (route) »» داده‌ها به صورت پویا مدیریت می‌شن و نیازی به تعریف نوع‌داده یا مسیرهای API نیست (routing).

- ذخیره داده‌ها در فایل JSON: داده‌هایی که با متدهای POST یا PUT می‌فرستیم سمتش در یک فایل JSON ساده ذخیره می‌شوند و نیازی به پایگاه داده وجود ندارد.

- نصب و راه‌اندازی آسون: هیچ پیش‌نیازی نداره و تنها با اجرای سرور، API آماده استفاده است. نصبش هم با کامندلاین یا داکر یا…

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

- چند سکویی: می‌تونید این ابزار را روی ویندوز، لینوکس و مک اجرا کنید، یا با استفاده از داکر.

- پشتیبانی از مدل‌های متنوع مثل GraphQL


📌 قابلیت‌های اصلی

- پشتیبانی از همه عملیات CRUD: منظورم متدهای HTTP مثل GET، PUT، POST، PATCH و DELETE.

- پشتیبانی از عملیات اطلاعات‌گیری از منابع: مثل HEAD و OPTIONS.

- مدیریت تأخیر و خطا: می‌تونید تأخیر و خطاها رو برای درخواست‌ها شبیه‌سازی کنید (مثلا بگید بعد از ۲ ثانیه پاسخ بده یا خطای ۵۰۲ برگردون).

- تایید هویت: از روش‌های توکن، Basic و کلید API پشتیبانی می‌کنه.

- پشتیبانی از WebSocket: برای دریافت اعلان‌های تغییر داده.

- پشتیبانی از فایل‌های استاتیک و Swagger: برای مستندسازی و تست API.

- فیلتراسیون، صفحه‌بندی و جستجوی متنی: برای مدیریت داده‌ها در سناریوهای پیچیده‌تر.

- پشتیبانی از GraphQL: قابلیت آزمایشی برای کوئری‌ها و Mutationهای GraphQL.

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

- پشتیبانی از فرمت‌های مختلف خروجی: شامل JSON، CSV و XML.

🛠 سرور جعلی JSON چجوری کار می‌کنه؟

جواب کوتاه: خیلی ساده 😅

جواب یه‌مقدار جزئی‌تر: سرور رو از طریق کامندلاین یا داکر اجرا کنید، شماره پورت و فایلی که APIها رو توش تعریف کردید و فایلی که داده‌ها رو می‌خواهید توش ذخیره کنید، ذکر کنید. تامام!

همون‌طور که عرض کردم این نوع نرم‌افزار، یک مفهوم رایج است، و منحصر به یک ابزار نیست. شاید معروف‌ترینش json-server با بیش از ۷۳هزار ستاره در گیت‌هابه! ولی مشابه دات‌نتی هم داره، dotnet-fake-json-server البته با ۳۸۸ ستاره 😂 و اینکه ۲ ساله آپدیت نشده و با دات‌نت ۶ توسعه داده شده، من این چند روز بعد از ساعت کاری، دارم روی ارتقا‌ئش روی دات‌نت ۹ کار می‌کنم و امیدوارم زودتر جمع شه و pull request بدم.

fake-server --file data.json --urls http://localhost:57602

جمع‌بندی: اگر با REST کار می‌کنید یا GraphQL حتمن OpenAPI و کار با این نوع ابزارها رو خوب و دقیق یاد بگیرید. اگر توی پروژه‌هاتون REST API زیاد دارید، خوبه که روی روش‌های tracing خصوصا وقتی APIها زنجیره می‌شن، دیزاین‌پترن‌های مرتبط با مایکروسرویس یا سیستم‌های توزیع‌شده رو تمرین کنید و هرگز بدون fake و test پیش نرید 😉

💬 اگر موضوع جالبی براتون هست بگید تا ویدیو کوتاه یا مثال بریم باهاش 😊

🚀 مقدمه‌ای بر GraphQL (بخش اول)

1.اصلا GraphQL چیه؟

به زبان ساده، GraphQL مکانیزمیه تا بتونیم با یک استاندارد مشخص، کوئری‌مون رو به «یک» API ارسال کنیم و داده‌ها رو دریافت. یعنی بابت هر داده‌ای که نیاز داریم دریافت کنیم سراغ یک REST API جداگانه نریم. بلکه فارغ از اینکه داده‌هامون یک جا هستن یا از منابع مختلفی تأمین می‌شن، صرفا می‌گیم «چی می‌خوایم با چه شرایطی» (مثلا تمام دانش‌آموزهای ۱۰ تا ۱۵ ساله که معدل بین ۱۷ تا ۱۹ داشتن) و بعد این کوئری رو ارسال می‌کنیم و پاسخمون رو می‌گیریم. و این عملا یک لایه‌ی واسط روی داده‌ها (متمرکز یا حتی توزیع‌شده + یک منبع داده یا چند منبع داده) به ما می‌ده که می‌تونه نیازهای توسعه‌دهنده‌های خودمون یا مشتریانمون رو برآورده کنه.


اینکه کاربر صرفا می‌گه چی‌ می‌خوام رو اصطلاحا "declarative data fetching" می‌گیم.

پیدایشش هم به سال ۲۰۱۲ برمی‌گرده که Lee Byron, Nick Schrock و Dan Schafer برای حل گرفتن دیتا برای اپلیکیشن‌های موبایل، توی فیس‌بوک دست به خلق GraphQL زدند، و بعدتر در سال ۲۰۱۵ به‌صورت کدباز عرضه‌اش کردند. به صورت سنتی مشکلات زیر در رابطه با REST API وجود داشت که منجر به پیدایش GraphQL شد، مثل:


- مشکل Over-fetching (دریافت داده‌هایی بیش از دیتای مورد نیاز، مثلا: ما ۳ تا فیلد رو نیاز داریم ولی API ما ۱۰ تا فیلد رو برمی‌گردونه، که این توی مقیاس بزرگ می‌تونه منجر به هدررفت منابع پردازشی و ارتباطی بشه)

- مشکل Under-fetching (دریافت داده‌هایی کمتر از اونچه نیاز داریم که منجر به درخواست‌های متعدد برای تکمیل داده‌های مورد نیاز است، مثلا: چند API رو صدا کنیم و داده‌های همه رو با هم ترکیب کنیم تا اونچه نیاز داریم رو از دلشون در بیاریم)

- انعطاف‌‌پذیری کم endpointها نسبت به نیازهای سمت front


✨ حالا چه مشکلاتی رو قراره برطرف کنه؟

- واکشی به‌اندازه و دقیق داده‌ها (هر دیتایی با هر شرط و فیلتری و هر ساختاری رو بتونیم واکشی کنیم)

- انعطاف پذیری API از منظر طراحی (پشتیبانی از طیف وسیعی از امکانات)

- یک endpoint برای چندین منبع داده (در مقابل شرایطی که برای هر سرویس یا منبع داده، یک گروه REST API ارائه می‌کنیم)

- ساختار strong typing


✨ مناسب برای…

- نرم‌افزارهای پیچیده و داده‌محور (دیتامدل‌های پیچیده، منابع داده متعدد «با تعریف استاندارد!! نه دلخواه مدیرعامل شرکت که حتی نرم‌افزار دفترتلفن رو توی لینکدینش پیچیده‌ترین نرم‌افزار جهان معرفی می‌کنه 😂😉)

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

- نرم‌افزارهای موبایل و فرانت‌اند با نیازهای داده‌ایِ پویا (دست فرانت‌اند دولوپر رو باز می‌گذاره تا هر چی خواست سریع توسعه بده)


✨ محدودیت‌هاش:

- افزایش پیچیدگی برای APIهای ساده (دقت کنیم کجا مناسبه برای استفاده از GraphQL)

- سربار پرادزشی بالقوه برای کوئری‌های پیچیده (نمیشه روی همه کوئری‌ها، همه حالت‌ها ایندکس گذاشت، کاربر می‌تونه یه کوئری بفرسته که باعث کُندی سیستم بشه!)

- راه‌اندازی اولیه نسبتا سنگین و زمان‌بری داره

- منحنی یادگیری برای تیم‌هایی که REST بلد هستن و دیدگاه REST API Design دارن کمی زمان‌بر و نیاز به تغییر دیدگاه داره


✨ چالش‌های بالقوه:

- مدیریت عمق و پیچیدگی کوئری‌ها نیاز به تحقیق و دقت زیادی داره

- مکانیسم caching پیچیده‌تر از REST است (گاهی خیلی پیچیده‌تر)

- مستعد مصرف منابع پردازشی زیاد

- ملاحظات امنیتی (پیچیدگی کوئری‌ها، محدودیت نرخ درخواست، امنیت در سطح داده و خصوصا لایه‌های دوم به بعد..)

===================
🌱🙏 یک درخواست: تلاش من برای ارائه مطالبیه که بتونه مفیدتر باشه، لذا فیدبک شما می‌تونه به من برای انتخاب «موضوع» و «عمق پرداختن به موضوع» خیلی کمک کنه. لذا یک قرارداد رو با هم بگذاریم، اگر دوست داشتید یک موضوع رو عمیق‌تر بررسی کنیم، لطفا با ری‌اکشن و ایموجی 🤓 به من بگید بگید لطفا، و اگر تعداد این ایموجی بالا رفت من متوجه خواهم شد که موضوع مورد علاقه بوده و باید با مثال و کد و توضیح بیشتر ادامه‌اش بدم.
===================

بخش دوم (ادغام شده با بخش اول) رو به دلیل محدودیت تلگرام در درج تصاویر متعدد، اینجا نوشتم که اگر علاقه‌مند بودید مطالعه کنید:
https://mesbahi.net/fa/blog/1403/09/15/graphql-intro/

برای ۲۰۲۵ چه برنامه‌ای داریم؟

حدود ۲ هفته دیگه سال جدید میلادی شروع می‌شه، از اونجایی که تکنولوژی‌ها، ابزارها و چیزهایی که ما باهاشون سر و کار داریم نسبت به تقویم میلادی برنامه‌ریزی و ارائه می‌شن، شاید بد نباشه اگر بررسی و برنامه‌ریزی یادگیری‌مون رو شروع کنیم 😉

👀 آخرین ساعت‌های ۲۰۲۵ قراره چه فرق‌هایی از نظر دانش و مهارت با ابتدای ۲۰۲۵ داشته باشیم؟

📚 ترندها، تقویم ریلیزها و... رو مرور کردیم؟ کتاب‌هایی که می‌خوایم بخونیم؟ کتاب‌هایی که قراره چاپ بشن؟ مثلا سرچ کردیم upcoming books فلان موضوع؟

📌 در مورد محصولاتمون چی؟ تقویم ریلیز داریم برای سال پیش‌رو؟ چک کردیم لایبری‌ها و ابزارهایی که استفاده کردیم آیا end of support در ۲۰۲۵ دارن که از الان براشون پلن کنیم؟

🐥🐥 خلاصه اینکه آخر سال یه جورایی وقتی جوجه شمردنه! ۲۰۲۴ چی کار کردیم که بهتره توی ۲۰۲۵ ادامه بدیم، بهبود بدیم، یا ازش پرهیز کنیم؟

اگر دوست داشتید گپ بزنیم در موردش 😀💬

⚙️ معرفی یک کتابخونه Workflow

این پروژه، یعنی Elsa یک کتابخونه مدیریت گردش کاره که UI خوبی هم براش توسعه داده شده (دو بخش داره، سرور، و رابط کاربری)

قابلیت‌های اصلی:
- اجرای workflow در هر اپلیکیشن دات‌نت (.NET 6 و بالاتر)
- پشتیبانی از workflows های کوتاه یا دائمی و طولانی‌مدت
- رابط گرافیکی وب با قابلیت drag & drop برای ساخت workflow
- اجرای موازی اکتیویتی‌ها
- پشتیبانی از اسکریپت‌نویسی پویا (C#، JavaScript، Python و Liquid)
سازگاری با دیتابیس‌های مختلف (EF Core، MongoDB و غیره)

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

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

💡شاید بد نباشه توی توسعه‌اش کمک کنید (چه سمت فرانت، چه سمت بکند)

🔗 پروژه السا سرور
🔗 پروژه السا استدیو (UI وب)
🔗 مستندات و راهنمای استفاده
⭐️ ستاره در گیت‌هاب ۶۶۰۰
🍴تعداد فورک در گیت‌هاب ۱۲۰۰

🚀 کتابخونه‌های جاوااسکریپتی که بهتره در 2025 باهاشون وداع کنید!

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

۱.‎ jQuery
- چون دوران طلاییش تموم شده!
- با API های جدید جاوااسکریپت و فریم‌ورک‌های مدرن‌تر مثل React و Vue، دیگه نیازی بهش نیست
- جایگزین: API های نیتیو جاوااسکریپت

۲.‎ Moment.js
- حجم سنگین (66 کیلوبایت)
- کند و ناکارآمد
- جایگزین: Date-fns یا Luxon
- آینده: API Temporal جاوااسکریپت

۳.‎ Lodash
- زمان خداحافظی رسیده!
- اکثر متدهاش توی +ES6 وجود داره
- جایگزین: متدهای نیتیو جاوااسکریپت
- توصیه: ایمپورت مدولار اگه واقعاً بهش نیاز دارید

۴.‎ Underscore.js
- کاملاً منسوخ شده
- همه قابلیت‌هاش توی سینتکس +ES6 هست
- جایگزین: متدهای بومی جاوااسکریپت

۵.‎ RequireJS
- با ورود ES6 Modules، دیگه معنایی نداره
- جایگزین: Webpack، Vite یا ماژول‌های ES6

اگر دوست داشتید این لیست رو توی کامنت تکمیل کنید 😉

📌 ربع‌بندی بدهی فنی (Technical Debt Quadrant)

دیروز یه توییتی زدم که برای توضیح بهتر منظورم (که هیچ ربطی هم به نرم‌افزار نداشت)، از توصیف بدهی فنی ناآگاهانه‌ی بی‌پروا استفاده کردم، این شد که گفتم شاید بد نباشه کمی عمیق‌تر در مورد بدهی فنی گپ بزنیم...

مارتین فولر سال‌ها پیش یک ربع‌بندی (Quadrant) برای طبقه‌بندی انواع بدهی ‌های فنی معرفی کرد که تا امروز هم قابل تعمیم و استفاده است، برای اینکه دید بهتری نسبت به بدهی فنی‌هامون داشته باشیم. برای «احمقانه»‌ها توجیه نتراشیم... بابت عاقلانه‌ترها هم خودمون رو بیش از حد سرزنش نکنیم.

1. بی‌پروا و غیرآگاهانه (Reckless & Inadvertent)
بدون آگاهی و بی‌برنامه ایجاد شده.

2. بی‌پروا و آگاهانه (Reckless & Deliberate)
تیم آگاهانه و به صورت بی‌پروا برای سرعت بخشیدن به کار ایجاد کرده.

3. محتاطانه و غیرآگاهانه (Prudent & Inadvertent)
به صورت تصادفی اما با رعایت اصول اولیه ایجاد شده.

4. محتاطانه و آگاهانه (Prudent & Deliberate)
آگاهانه و با برنامه‌ریزی برای دستیابی به اهداف کوتاه‌مدت ایجاد شده.

ری‌اکشن 🤓 برای اعلام تمایل برای توضیح بیشتر و مثال و...

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

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

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

لذا خواهشم اینه که حتی اگر هیچ یک از مطالب این کانال رو درخور مطالعه یا اشتراک گذاشتن با دیگران ندیدید، این یک مطلب، یعنی دوره‌های فارسی برنامه‌نویسی که code.org برای کودکان تهیه کرده، (یا هر منبعی که کمک می‌کنه به یک کودک تا مهارت در «حل مسئله»، و «شکستن مسایل بزرگ به بخش‌های کوچک‌تر و ساده‌سازی اون‌ها» کسب کنه)، با والدینی که می‌شناسید به اشتراک بگذارید...
دم هادی پرتوی، بنیاگذار code.org گرم
😊🌱🙏

#موقت
از دوستانی که منتظر ویدیو aspire و ویدیو توضیح بدهی فنی هستند، بابت تاخیر عذرخواهی می‌کنم. دسامبر خیلی شلوغی بوده تا امروز، امیدوارم طی روزهای آتی برسونم 😊🙏

📽 توضیح تکمیلی بر تحلیل ساختارمند بدهی فنی (کوادرانت فاولر)
پیش از هر چیز از دوستانی که با ری‌اکشن 🤓 برای بررسی عمیق‌تر موضوع بدهی فنی، ابراز علاقه کرده بودند متشکرم.

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

مقدمه: (0:00)
تعریف بدهی فنی: (0:37)
خصوصیات رایج بدهی‌های فنی: (3:15)
انواع بدهی فنی: (5:40)
لزوم بررسی ساختارمند بدهی فنی: (7:28)
کوادرانت (ربع‌بندی) مارتین فاولر: (12:30)
نوع اول-آگاهانه و منطقی: (13:30)
نوع دوم-ناخواسته و محتاطانه: (15:10)
نوع سوم-آگاهانه و غیرمسئولانه: (16:41)
نوع چهارم-ناآگاهانه و بی‌پروا: (17:37)
سایر طبقه‌بندی‌ها: (18:51)
جمع‌بندی: (22:35)

خیلی خوشحال می‌شم تا بهانه‌ای باشه برای هم‌فکری و گپ و گفت بیشتر 🌱💬😊

✨ تایپ هینت‌ها توی پایتون در سال ۲۰۲۴: محبوب ولی هنوز چالش‌دار


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

PEP 484 چیه؟
تایپ‌هینت توی زبان‌های داینامیک تایپ (Dynamic Typing) مثل پایتون یا جاوا اسکریپت، این امکان رو به توسعه‌دهنده‌ها می‌ده تا «نوع» داده‌ای ورودی‌ها و خروجی توابع و متغیرها رو مشخص کنن.
مثلا به جای:

def greet(name):
    return f"Hello, {name}!"

بنویسن:

def greet(name: str) -> str:
    return f"Hello, {name}!"

سال ۲۰۱۴، Guido van Rossum (خالق پایتون) و Jukka Lehtosalo (خالق mypy) امکان تایپ هینت (Type Hint) رو در قالب PEP 484 معرفی و به پایتون اضافه کردن. تایپ هینت اجباری نیست، یعنی کد پایتون بدون اون هم اجرا میشه، اما وقتی ازش استفاده کنیم، می‌تونیم توی پیدا کردن باگ‌های احتمالی، بهتر شدن تکمیل خودکار کد (autocomplete) توی IDEها و مستند‌سازی، از مزایاش استفاده کنیم.

ایده اصلی PEP 484 این بود که پایتون همچنان یک زبون داینامیک بمونه، ولی اگه کسی خواست، بتونه از تایپ‌ها برای بهبود کیفیت کد استفاده کنه. با این قابلیت، ابزارهایی مثل Mypy و Pyright می‌تونن تایپ‌ها رو بررسی کنن و خطاهای احتمالی رو قبل از اجرای کد پیدا کنن.


یکی از دلایل اصلی محبوب شدن تایپ‌ها تو پایتون PEP 484 بوده و باعث شده ابزارها و کتابخونه‌های زیادی ازش پشتیبانی کنن. حالا ده سال بعد از معرفی PEP 484، یه نظرسنجی بزرگ توسط JetBrains، Meta و مایکروسافت انجام شده تا ببینن وضعیت استفاده از تایپ‌ها تو پایتون چجوریه. بیش از ۱۰۰۰ نفر تو این نظرسنجی شرکت کردن و نتایج جالبی به دست اومده. خلاصه‌اش اینه:

نکات مهم:
- تقریبا ۸۸٪ برنامه‌نویسا یا همیشه یا اغلب از تایپ‌ها استفاده می‌کنن.
- مزایای اصلی، بهبود IDEها، داکیومنت‌ها و پیدا کردن باگ‌ها.
- مشکلات اصلی هم دشواری توی استفاده برای الگوهای پیچیده، کندی ابزارها و نبود تایپ تو کتابخونه‌های محبوب.
- تفاوت توی نحوه پیاده‌سازی تایپ چکرها و سختی پیدا کردن مستندات، کارو برای جونیورها سخت می‌کنه.

📌 کجاها از تایپ‌ها استفاده میشه؟
کوتاه: خیلی جاها 😁
کمی دقیقتر: از اسکریپت‌نویسی و توسعه وب گرفته تا دیتا ساینس، دیتا انجینیرینگ، هوش مصنوعی و... حتی برای پروژه‌های شخصی هم ۶۶٪ از تایپ‌ها استفاده می‌کنن.

⚙️ ابزارها و تایپ چکرها
- محبوب‌ترین محیط توسعه VS Code بوده.
- تو تایپ چکرها، Mypy اول و Pyright دومه.
- جالبه که Pydantic هم کلی استفاده میشه (۶۲٪)، حتی برای چک‌های زمان اجرا.

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

😤 مشکلاتی که اذیت می‌کنه:
- پیچیدگی تایپ‌ها برای چیزای داینامیک.
- سرعت پایین ابزارهایی مثل Mypy.
- نبود تایپ تو بعضی از کتابخونه‌ها.
- مستندات ناکافی، مخصوصاً برای موارد پیشرفته.

🧐 چرا بعضیا تایپ استفاده نمی‌کنن؟
- ۲۹٪ گفتن نیازی به تایپ تو پروژه‌هاشون ندارن. جالب اینکه حتی بین این افراد، ۶۰٪ تایپ رو "همیشه" یا "اغلب" استفاده می‌کنن.

✍️ پیشنهادها برای بهبود:
- استانداردسازی بهتر ابزارها.
- پشتیبانی قوی‌تر برای الگوهای پیچیده و داینامیک.
- بهبود مستندات، مخصوصاً برای تایپ‌های پیشرفته با مثال‌های عملی.
- افزایش سرعت تایپ چکرها.

🔄 این نظرسنجی قراره سال ۲۰۲۵ دوباره انجام بشه تا ببینن وضعیت تغییر کرده یا نه.

🔗 لینک نتایج نظرسنجی از بلاگ مهندسی شرکت متا

نظر شما چیه؟ از تایپ‌ها استفاده می‌کنی یا ترجیحت پایتون‌نویسی به شیوه مردان شجاع و فارغ از تایپه؟ 😅