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

دیشب 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.
- نبود تایپ تو بعضی از کتابخونه‌ها.
- مستندات ناکافی، مخصوصاً برای موارد پیشرفته.

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

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

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

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

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

📊 محبوب‌ترین API Clientها در سال ۲۰۲۴ به آمار Cloudflare

روزهای آخر ساله و شرکت‌های مختلف، آمار و ارقامشون رو می‌گذارن روی میز (مثل مطلب قبلی). حالا Cloudflare به عنوان پرمخاطب‌ترین CDN دنیا که به گزارش سال ۲۰۲۲ W3Techs حدود ۸۰٪ همه وب‌سایت‌ها ازش استفاده می‌کنن (سال ۱۴۰۰ هم آروان سهم کلودفلر رو بین سایت‌های ایرانی حدود ۷۰٪ ذکر کرد)، آمار API Clientها رو برای سال ۲۰۲۴ ارائه کرده.
اینا رو عرض کردم که بدونیم آمار و ارقامش قابل اتکا است. ولی:

✏️ در نظر بگیریم که کلودفلر CDN محبوب وب‌سایت‌ها است و خیلی از اپلیکیشن‌های سازمانی پشت کلودفلر نیستن، بلکه پشت CDNهایی مثل Azure CDN یا آمازون CloudFront هستند یا اصلا از CDN استفاده نمی‌کنن.

با این‌ توضیحات:

بر اساس گزارش جدید کلودفلر، زبان برنامه‌نویسی Go به محبوب‌ترین زبان برای توسعه کلاینت‌های API تبدیل شده و از Node.js پیشی گرفته. همچنین، AWS به‌عنوان انتخاب اصلی برای میزبانی وب‌سایت‌های عمومی در بین ۵۰۰۰ دامنه برتر شناخته شده.

جزئیات گزارش:
محبوبیت Go برای کلاینت‌های API: بیش از نیمی از ترافیک اینترنتی که کلودفلر مشاهده کرده، مربوط به APIهاست.

تحلیل‌هاشون نشان داده که Go با ۱۱.۸٪ استفاده، در صدر زبان‌های مورد استفاده برای توسعه کلاینت‌های API قرار داشته، از طرفی Node.js با ۱۰٪ و پایتون با ۹.۶٪ در رتبه‌های بعدی بودن.

این تغییر نسبت به سال گذشته قابل توجه است، چرا؟ چون سال گذشته Node.js با ۱۴.۶٪ در صدر بود و Go با ۸.۴٪ در رتبه دوم قرار داشت.

میزبانی وب‌سایت‌های عمومی: در بین ۵۰۰۰ دامنه برتر، AWS با ۶۲.۳٪ سهم، پیشتازه: در مقابل، مایکروسافت Azure فقط ۴.۸٪ سهم داشته و بعدش هم WP Engine با ۸.۵٪ و Vercel با ۶.۱٪ قرار داشتن.

فریم‌ورک‌ها و کتابخونه‌های وب: توی این دامنه‌ها، PHP با ۴۸.۱٪ به‌عنوان محبوب‌ترین زبان برنامه‌نویسی بوده (یحتمل به خاطر وردپرس و...)، بعدش هم Node.js با ۲۷.۹٪ و جاوا با ۱۶.۸٪ قرار داشتن. در بین فریم‌ورک‌های جاوااسکریپت، React با ۳۶.۶٪ در صدر بوده و بعدش Vue.js با ۱۹.۷٪ و Next.js با ۱۲.۶٪ قرار داشتن.

🔗 لینک گزارش


👀 این اعداد به هیچ وجه به معنی برتری یا ترجیح یا حتی محبوبیت مطلق این ابزارها و تکنولوژی‌ها نیست! 😊

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

🚀 تبدیل فایل‌های پی‌دی‌اف و آفیس و... به Markdown!

یک کتابخونه خوب پایتونی از مایکروسافت! (+ یک اپلیکیشن که با استفاده ازش ساخته شده) برای تبدیل فایل‌های
- PDF (.pdf)
- PowerPoint (.pptx)
- Word (.docx)
- Excel (.xlsx)
- Images (EXIF metadata, and OCR)
- Audio (EXIF metadata, and speech trannoscription)
- HTML (special handling of Wikipedia, etc.)
- Various other text-based formats (csv, json, xml, etc.)

به Markdown!

توضیح اضافه ندم که چقدر می‌تونه برای تبدیل ساده مستندات سنتی و... به ابزارهای مدرن ویکی یا نگهدارای مستندات مفید باشه!

from markitdown import MarkItDown

markitdown = MarkItDown()
result = markitdown.convert("test.xlsx")
print(result.text_content)

https://github.com/microsoft/markitdown

♻️💡 نظرسنجی در مورد محتوای کانال

سلام به همگی 😊

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

لینک زیر یک نظرسنجی کوتاه و فقط ۵ سوال انتخابیه (و البته به صورت ناشناس) که با شرکت در اون کمک مهمی در مسیر آینده کانال و بهبود محتواش خواهید داشت...
دم شما گرم، منتظر پاسخ‌ها، نقدها، نظرها و پیشنهاداتتون هستم 😉
https://forms.gle/Qu8xC8PvxcUP8fAx5

📚📚 بریم برای گپ و گفت در مورد کتاب‌هایی که سال ۲۰۲۴ خوندیم (حالا کامل، یا فصل‌هایی که جالب بوده برامون)

این مطلب بسته به استقبال شما می‌تونه از ذکر اسم کتاب، تا خلاصه صوتی مطالب متغیر باشه!

از خودم شروع می‌کنم (بخش اول، کتاب‌های جدید؛ بخش بعدی: کتاب‌هایی که بیشترین تعداد رجوع مجدد بهشون داشتم):

Architecture Modernization: Socio-technical alignment of software, strategy, and structure
سال انتشار: ۲۰۲۴
نویسنده: Nick Tune, Jean-Georges Perrin

——————
Patterns of Distributed Systems
سال انتشار: ۲۰۲۳
نویسنده: Unmesh Joshi
——————
ALEX KARP: From Philosophy to Palantir - A Life of Vision, Innovation, and Leadership
سال انتشار: ۲۰۲۴
نویسنده: Herbert K. Howard
——————
Clean Architecture with .NET
سال انتشار: ۲۰۲۴
نویسنده: Dino Esposito
——————
Programming Large Language Models with Azure Open AI: Conversational programming and prompt engineering with LLMs
سال انتشار: ۲۰۲۴
نویسنده: Francesco Esposito
——————
💸💸 انتشارات Packt مثل سال‌های پیش، از امروز به مدت چند روز تمام کتاب‌هاش رو فقط با ۹ یورو می‌فروشه!

🌟 ساده نگه داشتن سیستم‌ها، ۶ درس از Werner Vogels

حرف‌های زیادی میشه درباره AWS زد، اما واقعیت اینه که این غول کلود، سیستم‌ها و سرویس‌هاش رو طی دو دهه با موفقیت scale کرده و همچنان کاربری راحتش رو حفظ کرده.

ورنر فوگلس، CTO آمازون، تو کنفرانس AWS re:Invent درس‌های جذابی از تجربه‌اش تو نگهداری سیستم‌های پیچیده مطرح کرد.

💫 نکته کلیدی؟ پیچیدگی همیشه توی طراحی سیستم‌ها کمین میکنه، پس مهندس باید هوشیار باشه.

💫 هدف این نیست که پیچیدگی رو کلا حذف کنیم، بلکه باید اون رو مدیریت کنیم. لری تسلر میگه: "پیچیدگی رو نمیشه حذف کرد، فقط میشه جابجاش کرد".

یه مثال جالب: طراحی دوچرخه!

یک چرخه: خیلی انعطاف‌پذیره، اما سوار شدنش سخته
سه چرخه: راحته، ولی جابجا کردنش سخته
دوچرخه: تعادل ایده‌آل بین راحتی و انعطاف‌پذیری

۶ توصیه Vogels برای مدیریت پیچیدگی:

۱. سیستم‌های قابل تکامل بسازید
نرم‌افزارهایی که پیش نمیرن، میمیرن
هر بار که مقیاس سیستم عوض میشه، باید معماری رو بازنگری کنید

۲. پیچیدگی رو خرد کنید
تغییرات کوچک رو نادیده نگیرید
هر سرویس باید اونقدر کوچک باشه که تو ذهن یه مهندس جا بشه

۳. معماری رو با نیازهای کسب‌وکار هماهنگ کنید
اجزای هوشمند با رابط‌های ریزدانه بسازید
با واحدهای کسب‌وکار همکاری کنید

۴. کار رو به سلول‌ها تقسیم کنید
معماری سلولی پیچیدگی رو مدیریت میکنه
مشکلات رو محدود میکنه بدون تاثیر روی کل سیستم

۵. سیستم‌های پیش‌بینی‌پذیر طراحی کنید
عدم قطعیت رو کاهش بدید
از معماری‌های با پالس ثابت استفاده کنید

۶. همه چی رو اتوماتیک کنید
اتوماسیون استاندارد باشه
فقط جاهایی که نیاز به قضاوت انسانی هست، دخالت انسان لازمه

💫 خلاصه کلام: "سادگی نیاز به انضباط داره" - Werner Vogels

در موردش صحبت کنیم؟ نظر شما چیه؟

خب، ممنون از همه دوستانی که طی ۲۴ ساعت گذشته مشارکت کردن 🙏🌱

📌 نتیجه می‌گیرم در دورهمی بعدی، در مورد سیستم‌های توزیع‌شده گپ خواهیم زد.

ولی چون Semantic Kernal و AI هم فقط ۲ تا رأی فاصله داشت، دورهمی بعدش به احترام رفقایی که نظرشون روی کاربرد هوش‌مصنوعی بود، به اون خواهیم پرداخت.

من سعی می‌کنم زودتر برنامه‌ریزی کنم. ولی فعلا خوشحال می‌شم توی کامنت یا ایمیل، دغدغه و نکاتی که بیشتر دوست دارید در موردش بدونید در رابطه با Distributed Systems برای بنویسید 😊