یه انفوگرافی خوب از سیر امکانات جدید دات‌نت از نسخه ۱ تا ۹ و سی‌شارپ از نسخه ۱ تا ۱۳
منبع: nietras.com

توی نظرسنجی‌های توییتر، لینکدین و... چه خارجی و چه داخلی، خیلی‌ها رأی داده بودند به عدم مهاجرت به دات‌نت ۹ (به طور کلی نسخه‌های Short-Term Support).

ما کُد و رانتایممون رو باید به‌روز نگهداریم، چه برای آپدیت‌های امنیتی و چه پایداری. و این چیزی نیست که بشه ازش در این زمانه چشم‌پوشی کرد.

اینجا مستند مایکروسافت به طور رسمی بیان می‌کنه که ورژن‌های STS و LTS هر دو کیفیت و استاندارد یکسان دارن. فقط طول مدت به‌روز رسانی‌شون متفاوته. برای من خیلی دشواره که تصور کنم محیط اجرایی یا کد، یک سال متمادی دست نخوره و به‌روز نشه!

شما چه نظری دارین؟

✨ ‌‌‏DORA چیه؟
فریم‌ورک DORA که مختصر شده‌ی DevOps Research and Assessment است، یک فریم‌ورک برای تحقیق و ارزیابیه که تمرکزش روی بهبود مستمر تحویل نرم‌افزار در سازمان‌هاست. هدف DORA کمک به تیم‌ها و سازمان‌ها برای بهبود عملکرد و شناسایی نقاط ضعف فرآیند توسعه و عملیاتشونه. DORA بر اساس گزارش‌های سالانه مثل "Accelerate State of DevOps" و ۴ معیار کلیدی (DORA Metrics) شناخته می‌شه:
‎
اول: Lead Time for Changes
زمان لازم برای انتقال تغییرات کد به محیط تولید.

دوم: ‌‎Deployment Frequency
تعداد دفعات دیپلوی به محیط تولید.

سوم: ‎Change Failure Rate
درصد دیپلوی‌های ناموفق که باعث مشکلات در محیط تولید می‌شه.

چهارم: ‎Time to Restore Service
زمان لازم برای رفع خرابی و بازگرداندن سیستم به حالت پایدار.


🧐 به چه درد می‌خوره؟
فریم‌ورک DORA به تیم‌ها کمک می‌کنه تا عملکرد خودشون رو ارزیابی کنن و با استفاده از «داده‌» تصمیم بگیرن که کدوم بخش‌ها نیاز به بهبود دارن. گزارش‌های DORA به سازمان‌ها کمک می‌کنه تا با بررسی این معیارها، روند بهبود مستمر رو پیاده‌سازی کنن و بهترین عملکرد رو به دست بیارن.

⚙️ استفاده از DORA برای بهبود پایدار عملکرد مهندسی سازمانه، چند موضوع مهم:

🔹 چالش جمع‌آوری داده‌: به دست آوردن داده‌های دقیق برای متریک‌های DORA همیشه آسون نیست. ابزارهای اتوماتیک کمک می‌کنن، ولی هنوز هم تلاش زیادی برای ادغام این ابزارها در اکوسیستم سازمان نیاز هست.

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

🔹 تأثیرات پیاده‌سازی درست DORA: پیاده‌سازی درست DORA خیلی به رهبری و نحوه حمایت از اون بستگی داره. اگر تیم‌ها آزادی عمل داشته باشن تا بهبودهای خودشون رو انتخاب کنن، نتایج پایدارتری به دست می‌آد.

🔹تیم‌های موفق از استانداردهای صنعتی الهام می‌گیرن: تبیین قابلیت‌های DORA باعث می‌شه تا تیم‌ها بهتر بتونن معیارها رو درک کنن و از "این نظر منه" و "نظر تو چیه" فاصله بگیرن و به یک استاندارد صنعتی مشترک برسن.

🧾 نکات جالب از گزارش DORA 2024

🔸 رشد استفاده از هوش مصنوعی: پذیرش هوش مصنوعی داره به شدت رشد می‌کنه و تیم‌ها گزارش دادن که استفاده از AI باعث افزایش بهره‌وری، کیفیت کد، و سرعت بررسی‌های کد شده. با این حال، استفاده از AI تأثیر منفی کوچکی روی پایداری تحویل نرم‌افزار داشته.

🔸 مهندسی پلتفرم: گزارش اشاره کرده که تیم‌های استفاده‌کننده از پلتفرم‌های داخلی ۱۰ درصد بهره‌وری بیشتری داشتن، ولی کاهش ۸ درصدی در throughput و ۱۴ درصدی در stability هم مشاهده شده.

🔸 تثبیت اولویت‌ها: سازمان‌هایی که اولویت‌های پایدار دارن، بهره‌وری بیشتری دارن و سطح فرسودگی (burnout) کارکنان پایین‌تره.



❇️ خلاصه اینکه، روشمند و ساختاریافته در مورد فرایندهامون رفتار کنیم 😉

🔗 وب‌سایت DORA
🔗 گزارش سال ۲۰۲۴

✨ به بهانه رهانش پرومتئوس ۳ که بعد از سال‌ها یک تغییر بزرگ به شمار میاد، چند خطی در مورد خودش، کاربرد و تاریخچه‌اش و تغییرات نسخه ۳ به اختصار نوشتم...

اگر دوست داشتید بخونید و نظرتون رو در مورد روش‌های مانیتورینگ سرویس‌ها بگید...

🚀 در ویدیو مربوط به Aspire که به زودی تقدیم خواهم کرد، در مورد مفاهیم observability, trace, structured logging, opentelemetry صحبت کردم


https://mesbahi.net/fa/blog/1403/08/27/prometheus-3-overview/

✨ ♻️ مقدمه‌ای بر Scrumban!

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

همه چیز برمی‌گرده به فرهنگ تیم و مهارت لیدرشیپ و برنامه‌ریزی.
ولی روش‌ها هم هر از گاهی تغییرات یا نوآوری‌هایی نیاز دارن (البته نه برای همه، بلکه به جای درست و با پیش‌نیازهای درست). اسکرامبان ترکیبی از اسکرام و کانبان است. این چند سال هم اقبال خوبی بهش شده... سال ۲۰۱۷ توی یکی از جلسات همین تک‌افترنون، به تفصیل در مورد Agile, Scrum, CMMI توضیح دادم که ویدیوش توی آپارات بود. نکته اینه که هر تیمی با توجه به ساختار و نیازهاش و البته فرهنگش! روش متناسب با خودش رو باید انتخاب کنه، الزاما خفن‌ترین و کامل‌ترین، مفیدترین نیست...

سعی کردم چند خطی در موردش بنویسم و امیدوارم اگر چالش مدیریت تسک‌ها و برنامه‌ریزی تولید دارید، بخونید و 💬 در موردش نظرتون رو بنویسید...

https://mesbahi.net/fa/blog/2024/11/18/scrumban-intro/

🎇 رویداد Microsoft Ignite 2024 و آینده‌ی SQL Server

رویداد Microsoft Ignite یکی از مهم‌ترین رویدادهای سالانه مایکروسافته که تمرکز اصلیش روی ارائه آخرین نوآوری‌ها، تکنولوژی‌ها و پیشرفت‌های Azure و خدمات ابری، دیتابیس‌، DevOps، هوش مصنوعی و امنیته. رویداد امسال هم مثل چند سال گذشته که تب AI حسابی داغ بوده، کلی معرفی محصول روی هوش مصنوعی داره که از فردا شروع می‌شه. یکی از موضوعات مهمش هم AI برای SQL Server است.

📢 جلسه: The SQL Server roadmap: The next generation database AI platform
🗓 چهارشنبه، ۲۰ نوامبر ساعت ۱۸ (به وقت تهران)
توی این جلسه قراره تا شاهد معرفی آخرین قابلیت‌های هوش مصنوعی که قراره در نسخه آینده‌ی SQL Server اضافه بشه باشیم. احتمالا متوجه می‌شیم که نسخه بعدی چیه و چه‌زمانی منتشر می‌شه، از طرف دیگه ابزارهای AI و ML که به صورت بومی توی Microsoft SQL Server و Azure SQL رونمایی می‌شن رو می‌بینیم. موضوعات جلسه:

- معرفی ‎AI-native capabilities که امکانات هوش مصنوعی رو به طور مستقیم در موتور SQL Server اضافه می‌کنه.
- پشتیبانی از مدل‌های ML: قابلیت اجرای مدل‌های ML از طریق T-SQL بدون نیاز به سرویس خارجی.
- بهبود ‎ AutoML integration از نظر عملکرد تحلیل داده و قابلیت‌های پیش‌بینی بدون نیاز به دانش عمیق از ML.

🤖 🤖 🤖 حالا بد نیست یه نگاه به بازار دیتابیس‌های سنتی بندازیم و بررسی وضعیت AI توی دیتابیس‌های مختلف

نسخه فعلی ‌‎ Microsoft SQL Server
بهبود یکپارچگی با Python و R: نسخه‌های قبلی ابتدا R و بعدتر Python به SQL Server اضافه شدن و امکان اجرای اسکریپت‌های Python و R رو به همراه داده‌ها فراهم کرده شده بودن.

امکانات ML Services: سرویس‌های یادگیری ماشین توی SQL Server یکپارچه هستن تا مدل‌های ML به سادگی روی دیتابیس آموزش ببینن و اجرا بشن.

اتصال و ادغام با Azure AI: امکان اتصال و ادغام SQL Server با سرویس‌های Azure AI برای استفاده از مدل‌های آماده و از پیش آموزش‌دیده.

🔴 دیتابیس سرور ‎Oracle Database 23ai
اوراکل به عنوان رقیب سنتی SQL Server توی نسخه 23 توجه ویژه‌ای به AI و ML داشت و عملا AI Vector Search رو هم به انجین آورد.

قابلیت In-database Machine Learning که مستقیماً توی دل دیتابیس انجین قرار داده باعث می‌شه بتونیم مدل‌های ML رو بدون انتقال داده به سرویس خارجی اجرا کنیم.

قابلیتAutoML هم به کاربر امکان پیدا کردن خودکار بهترین مدل‌ و تنظیمات رو برای داده‌های موجودش فراهم می‌کنه.

پشتیبانی از Python و SQLML: اوراکل هم از پایتون برای پیاده‌سازی مدل‌های ML پشتیبانی می‌کنه

🟢 ۳: سرور ‎PostgreSQL
بین دیتابیس‌های کدباز PostgreSQL هم به عنوان انجین خوشنام و پیشرو، قابلیت‌های AI و ML رو از طریق افزونه‌ها و پلاگین‌ها فراهم می‌کنه:

- افزونه pgml: افزونه‌ای برای Machine Learning که امکان آموزش و اجرای مدل‌ها رو از دل دیتابیس فراهم می‌کنه.

- یکپارچگی Python integration) ‎PL/Python) امکان نوشتن توابع Python و اجرا در داخل PostgreSQL ممکن می‌کنه.

- پشتیبانی از ابزارهای محبوب ML مثل TensorFlow و Scikit-learn که از طریق Python در دسترسه.

🟡 ۴: سرور ‎MySQL
MySQL با وجود محبوبیت زیاد، از لحاظ قابلیت‌های بومی AI و ML از رقبا عقب‌تره! که البته از Oracle جز این انتظار نمی‌ره! از روزی که MySQL کم‌توجه بوده بهش 😏

✨ ✨ 🧞‍♂️ انتظارات از نسخه بعدی Microsoft SQL Server
با توجه به تمرکز مایکروسافت روی AI، می‌شه «حدس زد» که قابلیت‌های زیر در نسخه‌های آتی SQL Server اضافه بشه (فقط حدس منه، خبر نیست!):

- قابلیت AI-driven Query Optimization: استفاده از هوش مصنوعی برای بهبود عملکرد کوئری‌ها و کاهش زمان پاسخگویی.
- بهبود AutoML Integration: یکپارچگی بیشتر با سرویس‌های AutoML Azure و امکان آموزش مدل‌های پیچیده‌تر.
- اضافه شدن Native AI Functions: اضافه شدن توابع پیش‌فرض AI مثل توابع پیش‌بینی و دسته‌بندی به T-SQL.
- تمهیدات Data Privacy & AI: استفاده از AI برای تضمین امنیت و حریم خصوصی داده‌ها در دیتابیس.

👨‍💻 نظر شما چیه؟ چهارشنبه این جلسه رو می‌بینید؟ کاربرد AI توی دیتابیس انجین براتون جذابیت/کاربرد داره؟

صفحه رسمی رویداد
صفحه رسمی جلسات رویداد Ignite 2024

✨ 🎰 مفهوم Never-Ending Support و یک بیزنس مدل جالب!

تیم herodevs بیزنسش اینجوریه که می گه شما به هر دلیلی امکان ارتقاء فلان لایبری کدباز که دیگه پشتیبانی نمی‌شه رو نداری؟ اشکال نداره! ما پول می‌گیریم روی هر محصول کدباز عهد حجری‌ای بهت تا ابد سرویس و بهبود امنیتی می‌دیم.

مثلا روی Angular 1.5.x یا...

شاید برای مشتری‌ها جالب باشه، ولی طفلکی اون دولوپرهایی که باید سوار ماشین زمان شن و برگردن گذشته رو ترمیم کنن 😬😩🥴

❇️ رویداد بزرگ 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/