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

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


اگر علاقه‌مند بودید تا متن کامل رو همراه با دلایل اهمیت توجه به جذب کارآموز به شکل مدون و اصولی بخونید و تجربه این دانشجو و مشاهدات رو ببینید، اینجا توی وبلاگم نوشتم 😊

قابلیت‌های جدید C# 13
Params Collections
مستندات کامل

Clean Architecture یا Vertical Slice Architecture?
رفرنس جهت شروع!

⚡️در حالیکه Avalonia به عنوان تنها گزینه حال حاضر دات‌نتی‌ها به شمار میاد که ویندوز، مک، لینوکس رو به خوبی ساپورت کنه، و عملا .NET MAUI در پشتیبانی از لینوکس کاهلی می‌کنه و توسعه‌دهنده‌ها رو کمی نا امید کرده.
ابزار LINQPad محبوب هم به زودی با Avalonia به مک میاد و به جمع استفاده‌کننده‌هایی مثل KLM و JetBrains و...
وقتی نگاهی به گیتهاب MAUI بندازیم، مباحثه First class Linux support developed by Microsoft که از سال ۲۰۲۱ شروع شده، با چیزی حدود ۱۹۰ کامنت و نزدیک به ۷۰۰ ریپلای به کندی پیش می‌رود و برنچ‌ها، چیزی از توسعه فعال پشتیبانی از لینوکس نمی‌گوید!

✨ به بهانه ریلیز نسخه پیش‌نمایش هفتم از دات‌نت ۹، و نزدیک شدن به ماه نوامبر و انتشار نسخه نهاییش، خوبه که تغییرات، خصوصا breaking change ها رو مرور کنیم

۱۲ تا ۱۴ نوامبر ۲۰۲۴
۲۲ تا ۲۴ آبان ۱۴۰۳
کنفرانس NET Conf 2024.
رهانش نسخه نهایی NET 9.0.
موضوعات اصلی:

- Cloud Native
- AI-Powered Apps
- Blazor and Beyond
- Cross-Platform Excellence
متن خبر

📚خیلی مشتاقم تا این کتاب رو که قراره اکتبر ۲۰۲۴ عرضه بشه بخونم. نویسنده عالی (Vlad Khononov) و موضوع عالی.
چیزی که زیاد با تیم در موردش بحث داشتم و خیلی‌هامون درگیرش هستیم. اینکه توازن بین درهم‌تنیدگی وابستگی‌ها چقدر باشه، گاهی برای loose coupling شورش رو در میاریم، گاهی هم مثل آجرهای یک دیوار چنان tight coupling داریم که به هیچ چیز نمی‌شه دست زد.
خلاصه اینکه کتاب خوبی در راه است...

✨✨ Retry Pattern یا الگوی بازکوشش

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

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

💡 الگوی Retry Pattern چیه؟ الگوی Retry Pattern یکی از الگوهای معماری در توسعه نرم‌افزار است که به ما اجازه می‌ده تا در صورت بروز یک شکست موقت (Failure)، درخواست رو به‌صورت خودکار، مجدداً امتحان کنیم. به جای اینکه بلافاصله شکست را قبول کنیم و کل فرایند رو با خطا به اتمام برسونیم، سیستم تلاش می‌کنه تا درخواست را پس از یک تأخیر کوتاه دوباره ارسال کنه. این الگو به خصوص در سرویس‌های ابری که در معرض ناپایداری‌های موقت هستند، بسیار مفیده.

🔧 چگونه این الگو کار می‌کند؟ فرض کنید اپلیکیشن شما قصد داره به یک API خارجی درخواست ارسال کنه، اما به دلیل مشکلاتی مثل قطع موقت شبکه یا محدودیت سرعت در سمت سرور، درخواست با شکست مواجه می‌شه. در چنین شرایطی، به جای توقف عملیات، سیستم شما می‌تواند به‌طور خودکار درخواست را پس از یک زمان‌بندی خاص (مثل ۱ ثانیه، ۳ ثانیه، ۵ ثانیه) دوباره ارسال کند. این روند می‌تواند چندین بار تکرار شود تا زمانی که یا درخواست موفقیت‌آمیز باشد یا به حداکثر تعداد تلاش‌ها برسه، حتی مثلا بعد از ۵ تلاش ناموفق، به آدرس دیگه‌ای درخواست بفرسته (به‌صورت کلی: شما دستورالعمل چگونگی مواجهه با خطا رو تعیین می‌کنید).

📝 یک مثال ساده: تصور کنید یک اپلیکیشن دارید که باید اطلاعات آب‌وهوا را از یک API دریافت کنه. در اولین تلاش، به دلیل مشکلات موقتی در سرور API، درخواست شما شکست می‌خوره. به جای اینکه اپلیکیشن به کاربر پیام خطا نشان بده، از الگوی Retry استفاده می‌کنه و پس از چند ثانیه دوباره تلاش می‌کند، بعد از ۳ تلاش ناموفق، ۱ درخواست به API دیگه می‌فرسته، و اگر اون هم جواب نداد، اون وقت به کاربر خطا نشون می‌دید. ولی اگر در تلاش دوم یا سوم، درخواست موفقیت‌آمیز باشد، کاربر هرگز متوجه شکست اولیه نمی‌شه و تجربه کاربری بهبود می‌یابد.

🔑 نکات مهم:

1. حداکثر تعداد تلاش‌ها: همیشه باید یک محدودیت برای تعداد دفعاتی که درخواست تکرار می‌شود تعیین کنید تا از ایجاد بار اضافی بر روی سرورهای خارجی جلوگیری شود.
2. تأخیر بین تلاش‌ها: بهتر است بین هر تلاش کمی تأخیر بگذارید و این تأخیر می‌تواند با هر بار تلاش بیشتر شود (مثلاً ۱ ثانیه، ۲ ثانیه، ۴ ثانیه).
3. پیش‌بینی شکست‌ها: این الگو فقط برای شکست‌های موقت مناسب است و در مواردی که مشکل دائمی است (مثلاً آدرس API اشتباه است)، نباید استفاده شود.
4. راهکار جایگزین: همیشه بدترین سناریو رو تصور کنید و ببنید آیا می‌شه در اون حالت هم کاری کرد که کاربر خوشحال‌تر باشه، سیستم پایدارتر باشه؟!

📘 برای پیاده‌سازی:
Polly برای معروف‌ترین کتابخونه برای NET. است مثال
Microsoft.Extensions.Http.Resilience کتابخونه ساده‌تر، سبک‌تر از Polly برای دات‌نت

tenacity برای پایتون
backoff برای پایتون

backoff برای گو
retry-go برای گو

✨ نظر شما چیه؟ تجربه‌ استفاده کدوم لایبری براتون بهتر بوده؟

✨✨ امکانات جدید کوپایلوت در ویژوال استودیو 2022 نسخه 17.11

چند روز پیش نسخه ۱۷.۱۱ ویژوال استدیو ریلیز نهایی شد (البته همون وقع ۱۷.۱۲ به کانال preview اومد) اگر شما هم کاربر گیت‌هاب کوپایلوت هستید و برای اطلاع از امکانات جدیدش کنجکاوید، همراه شید:

🫧 نسخه جدید امکانات و درک بهتری برای پرس‌وجو و بررسی کد داره، خصوصا در مورد سی‌شارپ! یک یادآوری: وقتی از codepilot استفاده می‌کنید با تایپ workspace@ می‌تونید در مورد فایل‌هایی که تو پوشه وجود داره سوال کنید. مثلا می‌شه گفت:
@workspace what services I developed, but were not injected in my startup class
حالا می‌شه سوالات جزئی‌تری پرسید، مثل:
@workspace What project can I run in my solution?
@workspace In my workspace, where is #methodname referenced?
@workspace Where does serialization occur in my solution?

ویژگی‌های جدید:

🔸 کوپایلوت چت: دیگه مستقیماً از copilot درباره متدها، کلاس‌ها و توابع خودتون سوال بپرسید. مثلاً اگر نیاز دارید عملکرد یک تابع را درک کنید، می‌توانید از کوپایلوت بخواهید توضیح بده که چه کار می‌کنه و چجوری ازش استفاده کنید. کافیه یه # قبل از اسم متد بگذارید، مثال:

- I have a test method named #methodName. How can I ensure that it’s being executed correctly?
- What are some optimizations that could be applied to #methodName?
- How does #methodName1 use #methodName2 and what issues should I look out for?
- /explain #methodName

🔸 درک و تفسیر بهتر از پروژه: کوپایلوت دیگه می‌تونه کل پروژه شما را بررسی کنه و با توجه به ساختار و ارتباطات کدها، پیشنهادات دقیق‌تری ارائه بده. به عنوان مثال، اگر بخشی از کد شما به چندین فایل مختلف مرتبط است (.pertial class, etc)، کوپایلوت می‌تونه این ارتباطات را شناسایی کرده و پیشنهاداتی بر اساس کل پروژه ارائه بده.

🔸 پیشنهادات بر اساس وب: اگر کوپایلوت نتونه خودش پاسخ دقیقی از دل کد شما پیدا کنه، می‌تونه بره سراغ وب و با سرچ کردن تلاش کنه تا طلاعات تکمیلی برای پاسخ به سوالات شما ارائه بده. مثلاً اگر از کوپایلوت درباره یک کتابخانه خارجی سوال کنید، ممکنه از طریق جستجو در وب اطلاعات مربوطه رو پیدا کنه.

🔸 بهبود تفسیر کد: کوپایلوت حالا بهتر از قبل می‌تونه کدهای پیچیده را تجزیه و تحلیل کنه و توضیحات واضح‌تری ارائه بده. مثلاً در مواجهه با یک الگوریتم پیچیده، می‌تونه قدم به قدم توضیح بده که هر بخش از کد چه کاری انجام می‌ده.


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

به‌زودی نکات خلاصه و سریعی برای توسعه‌دهنده‌های و DBAهای SQL Server که دوست دارن در مورد PostgreSQL بیشتر بدونن، خواهیم داشت...
#MSSQL_to_PGSQL

#MSSQL_to_PGSQL
شماره ۱، مقدمه

شماره ۲: مفاهیم اولیه کوئری‌نویسی
نام آبجکت در کوئری باید داخل ' ' قرار بگیره (متفاوت با T-SQL)

⚡️SQL Server:
- Single quotes ' ': Used for string literals.

- Double quotes " ": Used for delimited identifiers (e.g., to allow for spaces or reserved words as object names).

- Square brackets [ ]: Used for delimited identifiers, often preferred in SQL Server for objects that contain spaces or reserved keywords.

⚡️ PostgreSQL:
- Single quotes ' ': Used for string literals.

- Double quotes " ": Used for delimited identifiers. This is the only method to handle identifiers with special characters or reserved words.

- Square brackets [ ]: Not used or recognized in PostgreSQL for identifiers.

#MSSQL_to_PGSQL

شماره ۳: مفهموم دیتابیس قالب در PostgreSQL و تفاوتش با model در SQL Server
مطالعه بیشتر

#MSSQL_to_PGSQL

مواجهه و مدیریت رخدادهای فنی، خصوصا در سازمان‌ها و تیم‌های نرم‌افزاری، مهارت مهمیه، در این پست به مرور گام‌ها و نکاتی که باید در نظر داشته باشیم پرداختم.
بهانه‌اش هم رویدادی است که به زودی برای بررسی فنی فاجعه Crowdstrike و ویندوز برگزار خواهد شد تا هم از نظر فنی با کلی سازمان و متخصص امنیت و نرم‌افزار مرورش کنن. دلایل و ریشه‌هاش رو به چالش بکشن و برای آینده برنامه‌ریزی کنن...
دوست داشتید بخونید و نظرتون رو بگید...
https://mesbahi.net/fa/blog/1403/06/04/%d9%85%d9%88%d8%a7%d8%ac%d9%87%d9%87-%d8%a8%d8%a7-%d8%b1%d8%ae%d8%af%d8%a7%d8%af%d9%87%d8%a7%db%8c-%d9%81%d9%86%db%8c/

مصاحبه با David Fowler Distinguished Engineer در Microsoft

در شرکت‌هایی مثل گوگل، اپل، سیسکو، یا مایکروسافت افراد کمی هستند که عنوان Distinguished Engineer رو دارند، اگر براتون جالبه که بدونید حقوق یک Distinguished Engineer در اپل چقدره، چیزی بین ۱ تا ۱.۵ میلیون دلار در ساله!
مهندسان بسیار با تجربه و با دانش عمیق این عنوان رو می‌تونن داشته باشن. افرادی با این عنوان، معمولاً نقش‌های کلیدی در طراحی و توسعه تکنولوژی‌های پیچیده و نوآورانه دارن. و به عنوان رهبران فکری و مشاوران اصلی روی پروژه‌های بزرگ و استراتژیک، و به بهبود و پیشرفت تکنولوژی‌های شرکت کمک می‌کنن. به طور خلاصه، این عنوان به مهندسانی داده می‌شه که تأثیر زیادی بر روی تکنولوژی و آینده شرکت دارند.
حلا Postman معروف که باهاش APIهامون رو تست می‌کنیم، در بخش بلاگ فنی‌اش یک مصاحبه/پادکست‌طور با دیوید فولر رفته که در مورد گذشته و حال و کارهاش گپ بزنه.

بسیار شنیدنی و آموزنده...
* بخش مهمی از مسیر شغلی من بعد از خوندن یک مصاحبه Ray Ozzie حدود ۱۸-۲۰ سال پیش در آرکیتچر ژورنال شکل گرفت! شاید یک مصاحبه برای شما هم اثرگذار باشه!
لینک یوتیوب مصاحبه

✨🚀
سلام
این ایونت «احتمالا» بخش اول سری بنچمارکینگ است، قصد دارم اهمیت و نکات بنچمارکینگ رو مرور کنیم و در بخش اول، روی دات‌نت و اس‌کیوال سرور کار خواهیم کرد و اگر استقبال خوبی بشه، در بخش دوم روی روی لایبری‌های پایتون و گو کار کنیم.

این فرم ثبت‌نام است (جلسات تِک‌افترنون همه رایگان هستند) و اگر فکر کردید برای دوستان و همکارهاتون هم این وبینار می‌تونه جالب باشه، بهشون اطلاع بدید ;)

افزودن ایونت به تقویم گوگل
لینک گوگل‌میت جلسه

کانال تلگرام تک‌افترنون

✨💡درس‌هایی از ۴۰ سال توسعه نرم‌افزار

شاید شما هم Dave Farley رو با کانال یوتیوبی Continuous Delivery دنبال کنید. کانالی با ۲۰۸ هزار دنبال کننده (تا امروز) که مطالب خیلی خوبی رو در خصوص مهندسی نرم‌افزار ارائه می‌ده.

چند روز پیش آقای Farley، ویدیوی جدیدی منتشر کرد که در ۱۹ دقیقه درس‌هایی از ۴۰ سال توسعه نرم‌افزار رو مرور کرد.

1️⃣ دروس اولیه برنامه نویسی
- لذت دستکاری کد: در ابتدا مجذوب توانایی کنترل رفتار کامپیوتر با نوشتن کد شد، همین مشوق یادگیری بیشتر براش بوده!

- اهمیت درک اصول اولیه: یادگیری زبان اسمبلی درک دقیقی از چگونگی کارکرد کامپیوتر در سطح عمیق‌تر بهش داده که بعداً در حل مسائل پیچیده براش مفید بوده.

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

🧵

3️⃣ حرکت به سمت برنامه نویسی شی‌گرا و نرم‌افزارهای سیستمی
- مسیر برنامه‌نویسی‌اش از BASIC و اسمبلی به C و بعداً ++C بوده، و زمانی که برنامه‌نویسی شی‌گرا (OOP) رو یاد گرفته، نقطه عطفی بوده براش که ایده طراحی کد با روابط و ساختارهای منسجم و منطقی، و فراتر از چند خط کد رو بهش یاد داده.
- بعدتر در برنامه‌نویسی سیستم‌ (systems programming)، از جمله توسعه سیستم‌عامل، درایور و low-level firmware جایی بوده که حل مسائل‌ پایه‌ای و ایرادیابی‌های پیچیده رو بهش یاد داده.

4️⃣ کار با سیستم های توزیع شده
- تجربه‌ و درسی که از کار کردن با سیستم‌های توزیع‌شده به دست آورده رو مرور می‌کنه و می‌گه که پیچیدگی‌های اضافه‌ای که این سیستم‌ها برای ایرادیابی، کارآیی و پایداری همراه دارند رو چطور تونسته در عمل درک کنه. با سیستم‌های توزیع شده بوده که توسعه message-based programming و asynchronous processes رو به خوبی درک کرده.
- بر اهمیت درک سخت‌افزار و نرم‌افزار برای ایجاد زیرساخت موثر و کارآمد تاکید می‌کنه.

5️⃣ آشنایی با Continuous Integration و Agile Practices
- با نمونه‌های اولیه CI آشنا می‌شه و شروع به استفاده در فرایند توسعه می‌کنه، همچنین XP رو در اون زمان به عنوان متدولوژی توسعه در پروژه‌ها با کار می‌گیره.
- اهمیت تست نرم‌افزار، و نه فقط پیاده‌سازی رو درک کرده، و ارزش فریم‌ورک‌های تست مثل JUnit رو فهمیده.

6️⃣ ساخت سیستم‌های مستلزم کارایی بالا (High-Performance Systems)
- توضیح می‌ده که پیوستنش به یک استارتاپ برای توسعه یکی از سریع‌ترین مبادلات مالی جهان بهش کمک کرده تا آموخته‌هاش از سیستم‌های توزیع‌شده، CI و برنامه‌نویسی با عملکرد بالا رو گرد هم بیاره.
- مفهوم mechanical sympathy رو به خوبی فهمیده، اینکه چطوری سخت‌افزار روی بهینه‌سازی عملکرد نرم‌افزار تاثیر می‌گذاره

7️⃣ 💎 نکات کلیدی از مسیر شغلی
- یاد گرفته که یک رویکرد مهندسی صحیح برای توسعه نرم‌افزار است بالانس هوشمندانه‌ای بین مفاهیم انتزاعی و شناخت از سیستم‌های عملیاتی و واقعی است.
- بر اهمیت یادگیری مستمر پافشاری می‌کنه و تطبیق ابزارها و تکنیک‌های جدید، و پرورش فرهنگ توسعه مشارکتی و نوآورانه رو درس‌های مهم می‌دونه.


📌 آدمی که ۴۰ سال مداوم یاد گرفته و همین الان هم به‌روزترین مطالب رو یاد می‌گیره و یاد می‌ده این تجربه رو به اشتراک گذاشته. یاد یه مطلبی که ۲۰ سال پیش خوندم تحت عنوان how to be programmer in 10 years افتادم، زمانی‌ که کتاب‌ها مطالب رو با در ۲۴ ساعت و یا یک هفته و یک ماه می‌خواستن یاد بدن!

حرکت مداوم، پله پله و یادگیری مداوم رو فراموش نکنیم... 😉
لینک ویدیو اصلی
اگر دوست داشتید هم‌رسانی کنید