🧩 یه افزونه برای VS Code اینبار Error Lens

با نداشتنش آسمون به زمین نمیاد! ولی بودنش عصای دسته برای پیگیری راحت‌تر خطاها.
مثلا متن خطا یا اخطار رو جلو همون خطی که باعش شده نشون می‌ده

حدود ۵ میلیون دانلود داشته و ۵ ساله که فعاله. (چرا این اعداد مهمه؟ چرا باید به توسعه‌دهنده اصلی افزونه دقت کنیم؟ چون توسعه و پخش افزونه، ولو کاربردی و جالب، یکی از تله‌ها رخنه‌های امنیتی است)

📌 دریافت و نصب Error Lens
🖥 ریپازیتوری گیت‌هاب

📚 معرفی کتاب: T-SQL Fundamentals

این کتاب که الان ویراست چهارمش در دسترسه، یکی از بهترین کتاب‌ها برای درک عمیق SQL است. درسته که مایکروسافت منتشر کرده و از نظر محصولی متمرکز بر SQL Server است، ولی یادمون نره که پایه و اساس RDBMSها تفریبا یکیه، مثل خودروهای بنزینی که فارغ از سازنده و مدل، توی هر دوره‌ای خصوصیات ساختاری مشابهی دارن و در کارایی و امکاناته که با هم متفاوت می‌شن.

مثلا درک صحیح از Set Theory یا Predication Logic یا درک دقیق از ساختار انواع ایندکس‌ها یا منطق پردازش دستورات SQL توی MySQL و Oracle و SQL Server و PostgreSQL مشابه هم هستن.

اگر دولوپر یا دیتا آنالیست هستید، خوندنش رو توصیه می‌کنم، اگر هم از انجین دیگه‌ای استفاده می‌کنید و دنبال منبع خوب برای مفاهیم پایه هستید باز هم منبع خوبیه. (منظورم از مفاهیم پایه، مقدمات select نویسی نیست، اینه که query optimizer چجوری دستورات و تحلیل می‌کنه و چی باعث‌ میشه کوئری خوب یا بد بشه!)

ادامه در کامنت...
اگر شما هم پیشنهاد و نظری داری بنویسید

🟩 اندر احوالات Green Threads در نرم‌افزار

تردها و انواعشون
تردها (Threads) واحدهای اجرای کد هستن که می‌تونن به‌صورت هم‌زمان یا به‌توالی روی پردازنده اجرا بشن. این کار باعث می‌شه برنامه‌ها بتونن چندین کار رو به‌طور موازی انجام بدن. حالا تردها دو نوع کلی دارن:

⚙️ تردهای سیستم‌عاملی (Kernel Threads):
این تردها توسط سیستم‌عامل مدیریت می‌شن و هر ترد یک بخش از CPU و منابع سیستم رو به خودش اختصاص می‌ده. این تردها می‌تونن به‌طور هم‌زمان روی چندین هسته پردازنده اجرا بشن و از چند هسته CPU استفاده کنن، به همین خاطر توی پردازش‌های سنگین و چند هسته‌ای خیلی کاربردی می‌شن.

🌱 گرین تردها (Green Threads):
این نوع تردها در سطح برنامه و توسط خود برنامه یا یک کتابخونه مدیریت می‌شن و به سیستم‌عامل متکی نیستن. در واقع، این تردها همگی داخل یک ترد سیستم‌عاملی اجرا می‌شن، و به همین خاطر وزن کمتری دارن و منابع کمتری مصرف می‌کنن. اما چون به یک ترد سیستم‌عاملی وابسته هستن، نمی‌تونن هم‌زمان روی چندین هسته اجرا بشن.

————————-

🫧 گرین تردها توی چه زبان‌ها و تکنولوژی‌هایی استفاده می‌شن؟

▫️گو (Go): گرچه دقیقاً به اون‌ها گرین ترد نمی‌گن، ولی گوروتین‌ها توی Go توسط رانتایم Go مدیریت می‌شن و خیلی سبک و انعطاف‌پذیرن (یکی از نقطه‌قوت‌های گو که من رو جذب کرد همین پرفرمنس عالی گرین‌تردینگ در گو بود، عملا همه چیز گرین‌ترد است).

▫️جاوا: نسخه‌های اولیه جاوا از گرین تردها استفاده می‌کردن، چون این تردها پرتابل بودن. ولی جاوا بعدها به‌خاطر محدودیت‌های گرین تردها به سمت تردهای سیستم‌عاملی رفت.

▫️پایتون: تردهای پیش‌فرض پایتون وابسته به سیستم‌عامل هستن، کتابخونه‌هایی مثل Gevent و Greenlet به پایتون اجازه می‌دن تا رفتار مشابهی با گرین تردها داشته باشه.

▫️روبی: برخی نسخه‌های روبی، مثل JRuby، از گرین تردها پشتیبانی می‌کنن.

▫️ارلنگ (Erlang): پردازش‌های ارلنگ هم مشابه گرین تردها عمل می‌کنن و مدیریت اون‌ها داخل محیط اجرایی این زبان انجام می‌شه.

▫️دات‌نت (NET.)
توی NET.، گرین تردها به‌طور پیش‌فرض وجود ندارن (در مورد نسخه ۹ توضیح مبسوطی توی کامنت خواهم نوشت) چون این فریم‌ورک بیشتر روی تردهای سیستم‌عاملی تکیه داره. ولی چند امکان مهم داره که ویژگی‌های مشابهی رو فراهم می‌کنن:

- Async/Await و الگوی Task-Based Asynchronous Pattern (TAP)
- پورت‌های کامل I/O: این ویژگی، مخصوصاً روی ویندوز، برای مدیریت بهینه عملیات I/O به کار می‌ره و بدون ایجاد چندین ترد، امکان هم‌زمانی رو فراهم می‌کنه.
- کتابخانه‌های شخص ثالث: توی NET. یه سری کتابخونه وجود داره که سعی می‌کنن قابلیت مشابه Fiber رو ایجاد کنن، ولی خیلی خوب نیستن جدی‌شون نگیرید 😁
به‌طور کلی، .NET از تردهای سبکی مثل گرین تردها پشتیبانی نمی‌کنه، ولی با ابزارهایی مثل async/await و Thread Pool می‌تونین به نتایج مشابهی برسین!

————————

💡 استفاده‌ گرین تردها چیه؟

💎 اپلیکیشن‌های I/O محور: گرین تردها برای برنامه‌هایی که بار زیادی از عملیات ورودی و خروجی دارن، خیلی مناسبه، مثل برنامه‌هایی که اغلب منتظر دریافت داده از شبکه یا دیسک هستن.

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

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

💬 نظر، تجربه، بحث، خوشحال می‌شم توی کامنت بنویسید...

🐍 چرا پایتون ۳.۱۳ سریع‌تر و کاراتر شده؟

نسخه جدید Python 3.13، بهبودهای مهمی در زمینه پرفرمنس و قابلیت استفاده از چندین هسته پردازشی همراه شده که مسیر تازه‌ای برای برنامه‌نویسی باز می‌کنه. دو ویژگی مهم یعنی حالت Free-threaded و کامپایلر JIT رو مرور کنیم؟ همچنین امکان جدید REPL.

GIL و Free-threaded
از قدیم GIL (Global Interpreter Lock) توی پایتون یکی از چالش‌های اصلی بوده. این قفل باعث می‌شه که هر بار فقط یک ترد بتونه کدهای Python رو اجرا کنه. این مسئله زمانی که پردازش‌های سنگین CPU داری یا می‌خوای از پردازنده‌های چند هسته‌ای استفاده کنی، به یه مشکل تبدیل می‌شه. با ارائه حالت Free-threaded به صورت آزمایشی، Python 3.13 این امکان رو می‌ده که پردازش‌های موازی رو بهتر مدیریت کنن و از تمام هسته‌های CPU بهره ببرن. البته هنوز این حالت کاملاً بهینه نیست و روی کارایی پردازش‌های تک ترد اثر منفی داره. اما این یه قدم بزرگ برای Python محسوب می‌شه، چون می‌تونه در آینده به حذف کامل GIL منجر بشه.

کامپایلر JIT و بهینه‌سازی با «کپی و پچ»
کامپایلرهای JIT (Just-In-Time) به کدها اجازه می‌دن تا مستقیماً به کد ماشین تبدیل بشن و سریع‌تر اجرا بشن. تا پیش از این نسخه، بیشتر کامپایلرهای JIT در Python به شکل افزونه‌ و ابزارهای خارجی مثل PyPy در دسترس بودن. اما حالا Python 3.13 با یک کامپایلر JIT جدید به نام «کپی و پچ» ارائه شده که با استفاده از الگوریتم کپی و پر کردن بخش‌های مورد نیاز، مستقیماً کد ماشین رو تولید می‌کنه و از تبدیل‌های میانی صرف نظر می‌کنه. این الگوریتم باعث می‌شه Python به طور پیش‌فرض سریع‌تر عمل کنه و بیشتر از یک پردازنده معمولی استفاده کنه. در نتیجه، این کامپایلر Python رو به فضای زبان‌هایی مثل C و ++C نزدیک‌تر می‌کنه.

امکانات جدید در REPL
محیط REPL (Read-Eval-Print Loop) در Python 3.13 به‌روزرسانی‌های جالبی داشته. حالا قابلیت ویرایش چند خطی داره و دستورات متداول مثل exit و quit بهش اضافه شدن. همچنین، رنگ‌بندی پیش‌فرض و امکان مرور دستورات تاریخچه (F2) و حالت چسباندن (F3) تجربه کار با Python رو ساده‌تر و جذاب‌تر کرده. این تغییرات به Python کمک می‌کنه که برای مبتدی‌ها و حرفه‌ای‌ها به یه محیط کار راحت‌تر و مفیدتر تبدیل بشه. (اگر با REPL آشنایی ندارید توی کامنت خواهم نوشت 😊 )

سایر بهبودها
Python 3.13 به‌روزرسانی‌های مهم دیگه‌ای هم داشته، مثل Garbage Collector بهینه که تأخیرهای ناشی از پاکسازی حافظه رو کاهش می‌ده و پشتیبانی بهتر از دستگاه‌های موبایل.

در مورد توسعه‌دهندگان و شرکت‌هایی که روی Python کار می‌کنن، فان‌روسوم، خالق اصلی Python، پس از چند سال استراحت دوباره به تیم توسعه پایتون در مایکروسافت پیوست و همچنان به شکل فعالی در بهبود Python مشارکت داره. مایکروسافت هم با پشتیبانی از پروژه‌هایی مثل Pyjion که کامپایلر JIT مختص به Python هست، نقش مهمی در این بهبودها داره.

این نسخه از Python تمرکز زیادی روی بهبود عملکرد و استفاده بهینه از منابع داره و با توجه به این تغییرات، Python می‌تونه برای کاربردهایی مثل هوش مصنوعی، علم داده و توسعه نرم‌افزارهای بزرگ، انتخاب مناسب‌تری باشه. به نظر می‌رسه که این نسخه، شروعی باشه برای یه نسل جدید از Python که به نیازهای مدرن برنامه‌نویسان پاسخ بهتری می‌ده.

اگر براتون جالب بود بگید تا از مزایای دونستن پایتون به عنوان دولوپر غیر پایتونی، به عنوان دیتابیس ادمین، به عنوان دواپس‌کار و... بنویسم 😊

بعد از اینکه خندیدید 😁
در مورد دلیل توصیه به استفاده نکردن از Exception صحبت کنیم؟

🎙🎧 الوعده، وفا!
ممنون از همه دوستانی که با نظر یا نقدشون کمک می‌کنن تا در جهت تولید محتوای مفیدتر بیشتر تلاش کنم.
اپیزود دوم آماده شد 🎉

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

تعداد لایک‌ها اینقدری بود که در مورد Exception ها صحبت کنیم 😁
این بنچمارک ساده رو نوشتم ( به زودی با توضیحات بیشتر و لینک گیت‌هاب ) که نشون بدم:

۱: بهبود پرفرمنس Exception در دات‌نت ۹
۲: تفاوت چشمگیر استفاده از Exception با روش‌های جایگزین

📌 یادمون باشه، این اعداد مطلقا به معنی «امروز عصر، عصرِ عدم استفاده از Exception» و اراجیف عامه‌پسند نیست!
بلکه هرچیز به جای خودش مناسبه، ما باید تا جای امکان کد با کیفیت‌تری تولید کنیم و به خوبی تستش کنیم. شرایط استثنا رو پیش‌بینی کنیم تا کمتر درگیر Exception شیم. تکنیک‌های جایگزین هم مثل:
‏Result یا Try Patterns که عملا از زبون‌های فانکشنال وام گرفتیم یا Return Codes یا الگوی OneOf و Either باید به درستی استفاده شن.

کتابخونه‌های ErrorOn یا FluentResults یا language-ext جزو همین روش‌های کمکی هستند


🧐 بازم بیشتر بدونیم یا بسه؟
مثلا اینکه Explicit Error Handling در Go چه تفاوتی با رویکرد پایتون و #C‌ داره؟

💡چرا تیم مایکروسافت اج در حال جایگزینی React با وب کامپوننت‌ها هستند!

تیم مرورگر مایکروسافت اج در تلاش هستند تا کامپوننت‌های رابط کاربری که با React توسعه داده شده رو با web componentها جایگزین کنند تا سرعت و عملکرد بهتری برای کاربرانشون فراهم کنند. ایده اصلی اینه که با استفاده از یک “معماری مبتنی بر مارک‌آپ”، وابستگی به جاوااسکریپت کاهش پیدا کنه و پردازش کمتری در سمت کلاینت صورت بگیره.

اندرو ریتز، مدیر تیم Edge Fundamentals مایکروسافت، توضیح می‌ده که هدف تیمش تبدیل حدود ۵۰٪ از رابط‌های کاربری وب مبتنی بر React در اج به وب‌کامپوننت‌ها تا پایان سال ۲۰۲۴ است. انگیزه اصلی این پروژه عملکرد ضعیف رابط‌های کاربری مبتنی بر React بود، به ویژه در دستگاه‌های ضعیف یا قدیمی. استفاده گسترده از React در مایکروسافت منجر به ایجاد یک باندل بزرگ و پیچیده شده بود که بر عملکرد تأثیر منفی داشت.

تیم اج در ابتدا از React برای تمایز رابط کاربری خود از کروم استفاده کرده بود، اما حالا با پروژه WebUI 2.0، به دنبال بهبود عملکرد با استفاده از وب کامپوننت‌ها هستند. به عنوان مثال، رابط کاربری “browser essentials” رو که با کلیک بر روی آیکون قلب در نوار مرورگر فعال می‌شود، با وب کامپوننت‌ها بازسازی کردند.

بحث‌هایی توی کامیونیتی توسعه‌دهنده‌ها در مورد سختی استفاده از وب کامپوننت‌ها وجود داره و برخی معتقدند که فریمورک‌هایی مانند SolidJS قابلیت‌ها و سادگی بیشتری ارائه می‌دهند، در حالی که برخی دیگه به پایداری و قابلیت interoperable بین المان‌ها در وب کامپوننت‌ها وزن بیشتری می‌دن. ریتز می‌گوید که تیم او با تمرکز بر استفاده از عناصر داخلی HTML و CSS، تونسته توسعه را ساده‌تر کنه و هماهنگی بهتری بین توسعه‌دهندگان و طراحان ایجاد کنه.

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

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



مقاله کامل رو می‌تونید از اینجا بخونید 🙂

🎙🔒 موضوع اپیزود بعدی پادکست، طراحی امن باشه؟

مفاهیم secure by design یا safe coding یا SSDLC است.

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

🎙🖥 دورهمی آنلاین در مورد دغدغه عرفان 😁

کامنت امروز عرفان در مورد اینکه مباحث بنیادین چجوری یادمون بمونه، یا اصلا لازمه یا نه و... باعث شد به فکر این بیوفتم که دورهمی آنلاین داشته باشیم:
- موضوعات دیزاین و معماری و الگوهای طراحی و... رو «تا چه حد»، «چجوری»، یاد بگیریم که روشون مسلط باشیم و یادمون نره؟
- اصلا نیازه که همه چیز رو بلد باشیم؟ (چجوری تعادل رو بین نگاه واقع‌بینانه فردی با نگاه واقع‌بینانه نسبت به بازار کار و مصاحبه‌های شغلی پیدا کنیم)
- نقشه راه یادگیری و شغلی رو چجوری تدوین کنیم

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

زمان پیشنهادی: فردا جمعه ۲۷ مهر (۱۸ اکتبر) ساعت ۱۹ به وقت تهران، مدت زمان: ۴۵ تا ۶۰ دقیقه.

لینک گوگل میت، حضور همه باعث خوشحالیه و اگر صلاح دونستید به دوستانی که علاقه‌مند به موضوع هستند معرفی کنید 😊

🛎🛎🛎 یک ساعت دیگه شروع می‌کنیم 😊
همه دعوتن، خوشحال می‌شم ببینمتون...
لینک گوگل میت

🎬 ویدیو جلسه دورهمی که شامل گپ و گفت در مورد مطالب زیر بود آپلود شد

- منحنی فراموشی مطالب، منحنی یادگیری، تکنیک تکرار مطالب
- یادگیری نرم‌افزار در ۱۰ سال!
- تا چه حد و چگونه باید مباحث طراحی، معماری و الگوهای طراحی را یاد بگیریم تا بر آن‌ها مسلط شویم و فراموش نکنیم؟
- آیا لازم است که همه چیز را بلد باشیم؟ چگونه تعادل را بین یادگیری فردی و نیازهای واقعی بازار کار و مصاحبه‌های شغلی پیدا کنیم؟
- چگونه نقشه راه یادگیری و مسیر شغلی خود را تدوین کنیم؟
https://youtu.be/Ry2wZDNtv3c

امروز صبح خبری دیدم که قابل انتظار بود ولی ناراحت‌کننده! سایت codeproject.com تعطیل می‌شود!

سال‌ها قبل از پیدایش stackoverflow یا github یا حتی مرحوم codeplex، مرجع یادگیری و به‌روز موندن و اشتراک تجربه و کد همین codeproject بود.

من دات‌نت رو با نسخه ۱ شروع کردم 👴🏻 زمانیکه کتاب و منابع خیلی محدود بود.
و سهمی که codeproject در یادگیری من داشت خیلی زیاد بود (خصوصا مفاهیم شیء‌گرایی).

برای مدت طولانی، مقالاتی که دوست داشتم رو با کدهای ضمیمه‌اش PDF می‌کردم و ازشون برای خودم کتابخونه درست کرده بودم...

💡 ولی سایتی که خودش باعث به‌روز موندن بقیه بود، به‌روز نموند و از رقابت جا موند!

حتی مقالاتی که در مورد معماری زیرساخت و سرورها و تنظیمات دیتابیس‌های codeproject بود به من خیلی کمک کرد (بعدترها stackoverflow و نشر تجربه عالیشون از زیرساختشون یادگیری عالی برام داشت)

خلاصه اینکه این ادای احترامیه به مقوله‌ی نشر دانش و همه سرویس‌هایی که ما رو در جهت یادگیری آزاد و البته اصیل کمک کردند...

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

بیاین چند تا عدد رو ببینیم تا اهمیت طراحی امن رو بهتر درک کنیم (گرچه فجایع امنیتی سرویس‌های دولتی و خصوصی ایران طی چند سال گذشته هیچ عقوبت خاصی نداشته براشون!)

گوگل سال ۲۰۲۲ بالغ بر ۱۲ میلیون دلار، و مایکروسافت تنها طی سال ۲۰۲۱ مبلغ ۱۳.۷ میلیون دلار به هکرهای اخلاق‌گرا بابت برنامه باگ‌بانتی پرداخت کردن.

سال ۲۰۱۷ شرکت Equifax فقط ۷۰۰ میلیون دلار جریمه شد بابت ضعف برطرف نشده امنیتی در فریم‌ورک جاوایی Apache Struts که منجر به نشت ۱۴۷ میلیون مشتریش شد و در کل ۱.۴ میلیارد دلار هزینه روی دستش گذاشت!

متا سال ۲۰۲۲ طی یک فقره جریمه، ۲۲۷ میلیون دلار پرداخت کرد بابت نشت اطلاعاتش...

💡 🎙 منتظر نسخه بعدی پادکست باشید. سعی می‌کنم مرور خوبی روی مفاهیم طراحی امن، shift-left testing، کدنویسی امن داشته باشم...

به بهانه دیدار اسکات هنزلمن، در مورد نقش‌های سازمانی مثل
Developer Advocate
Developer Evangelist
Developer Relations Engineer
DevRel
بیشتر بدونیم؟ گپ بزنیم؟ نقش چنین افرادی، مسیر شغلی، وظایف و...؟

پینوشت: از اینکه تونستم از این آدم بابت سال‌ها یادگیری که ازش داشتم حضوری تشکر کنم، و بگم چقدر سافت‌اسکیل‌هایی که ازش آموختم ارزشمند بودن، خیلی خوشحالم 😊

✨✨ خبر خوب...

به‌روز رسانی: Webstorm هم شامل همین رویه شد، برای استفاده غیرتجاری رایگان شد.

✨ ‏Diff Authoring Time روشی برای اندازه عملکرد توسعه‌دهنده‌ها

آخرین نسخه پادکست Meta Tech، به موضوع ارزیابی و افزایش بهره‌وری توسعه‌دهنده‌ها از طریق متریک جدیدی به نام "Diff Authoring Time" (DAT) اختصاص داده. خلاصه‌ای از نکات مهم و روش‌های متا برای سنجش و بهبود بهره‌وری توسعه‌دهندگان با استفاده از این متریک DAT

—-
⚠️ این متن در مورد شرکت متا است، شرکتی بی بیش از ۴۵هزار توسعه‌دهنده که ه فیسبوک، اینستاگرام، واتساپ و کلی ابزار high-tech تولید می‌کنند. متا از git استفاده نمی‌کنه و Mercurial رو به‌عنوان سیستم کنترل سورس داخلی خودش استفاده می‌کنه. پس خیلی با عموم شرکت‌ها فرق داره، این متن رو خواهشا با دید آگاهی و ایده گرفتن در مورد «نگاه سیستماتیک به ارزیابی عملکرد» افراد ببینیم! خواهشا راه نیوفتیم از فردا توی هر شرکتی تایم بگیریم ببینیم کی کارا تره 😅
—-

🔸 مقدمه و معرفی: ‏DAT چیه و چرا اهمیت داره؟
در متا به هر تغییر توی کد diff یا همون pull request توی بقیه سیستم‌ها می‌گن. DAT قراره زمان واقعی‌ای که برنامه‌نویس‌ها برای ساخت و تغییر diffها صرف می‌کنن رو اندازه بگیره. حالا شاید بپرسید "چرا اصلاً بخوایم این کار رو بکنیم؟" خب، اگه یه سیستم داشتی که دقیقاً نشون بده کجاها زمان زیادی صرف می‌شه یا کجاها کار گره می‌خوره، می‌تونستی با دید بازتر روی ابزارهای درست سرمایه‌گذاری کنی و تجربه کاری رو بهتر کنی. مثلاً می‌فهمی کجاها باید به بهینه‌سازی سرعت ابزارها بپردازی تا تیم‌ها سریع‌تر به نتیجه برسن.


🔸 نحوه پیاده‌سازی و جمع‌آوری داده‌ها
تله‌متری سیستم + داده‌های IDE: این متریک با استفاده از داده‌های سیستم‌عامل و محیط‌های توسعه (IDE) زمان واقعی فعالیت‌های کدنویسی توسعه‌دهندگان رو ثبت می‌کنه.
الگوریتم‌های ردیابی فعالیت: هر زمان توسعه‌دهنده در IDE فعاله، تایمر DAT روشن می‌شه. این تایمر هنگام وقفه‌های کاری (مثل ترک کردن سیستم) متوقف می‌شه. این نسخه، پنجمین تکرار الگوریتم DAT است که بهینه‌سازی‌ها و دقتش به‌مرور افزایش یافته.
پشتیبانی چند محیطی: DAT به‌طور کامل در محیط‌های متداول توسعه مثل VS Code و Android Studio اجرا می‌شه. اگر توسعه‌دهنده همزمان روی چند diff کار کنه، DAT می‌تونه فعالیت رو به تفکیک IDE‌های مختلف شناسایی و زمان‌بندی کنه.

🔸 داده‌های کلیدی و یافته‌ها
میانگین زمان DAT: به‌طور متوسط، هر diff حدود ۵۰ دقیقه زمان می‌بره. این زمان شامل فعالیت‌های IDE و ابزارهای مرتبط با کدنویسی می‌شه.
سطح پوشش: DAT در حال حاضر ۸۷ درصد diffهای واجد شرایط (diffهای نوشته‌شده توسط توسعه‌دهنده) رو پوشش می‌ده، و الباقی موارد به دلیل استفاده از ابزار، از دامنه اندازه‌گیری خارج می‌شه.

🔸 فرآیند اعتبارسنجی و بهبود DAT
فرایند اعتبارسنجی چندمرحله‌ای: برای اطمینان از صحت داده‌های جمع‌آوری‌شده، تیم متا سه مرحله اعتبارسنجی رو روی DAT انجام داده که این اعتبارسنجی شامل بررسی نمونه‌ای، مقایسه با نسخه‌های قبلی DAT، و سنجش میزان پوشش و دقت اون می‌شه.
تست‌های A/B: یکی از کاربردهای مهم DAT در آزمایش‌های A/B برای ارزیابی تأثیر ویژگی‌های جدید IDE‌ها و زبان‌های برنامه‌نویسیه. مثلاً اگر ویژگی جدیدی به یک زبان اضافه بشه، تیم توسعه می‌تونه با استفاده از DAT تأثیرش رو روی بهره‌وری توسعه‌دهنده‌ها بررسی کنه.

🔸 کاربردهای DAT و تحلیل داده‌ها
تحلیل مقایسه‌ای بین تیم‌ها: DAT امکان مقایسه تیم‌ها یا ابزارهای مختلف رو فراهم می‌کنه تا بتونه تغییرات بهره‌وری رو شناسایی کنه.
شناسایی نقاط ضعف و بهبود فرآیندها: با بررسی DAT، تیم‌ها می‌تونن بخش‌هایی از فرآیند کدنویسی رو که باعث کاهش بهره‌وری شده، شناسایی و بهبود بدن.
بررسی تأثیر ابزارها و افزونه‌های جدید: آزمایش و مقایسه ابزارهای جدید با استفاده از DAT به تیم‌ها کمک می‌کنه تا تأثیر تغییرات رو با داده‌های کمی ارزیابی کنن.

🔸 آینده DAT
توسعه و ساده‌سازی DAT: هدف تیم توسعه‌دهنده DAT در نسخه‌های آتی، ترکیب و ساده‌سازی این متریک به نحویه که تنها یک عدد نهایی برای زمان ایجاد diff ارائه کنه.
پشتیبانی از کدنویسی خودکار توسط هوش مصنوعی: با رشد استفاده از هوش مصنوعی و کدهای تولید شده توسط LLMها، DAT به سمتی می‌ره که بتونه این نوع فعالیت‌ها رو هم به عنوان بخش جدیدی از بهره‌وری پوشش بده.

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