مسعود بیگی

تو مواجهه با روزهای بدتون کدومید بیشتر؟

نقش Forward Deployed Engineer یا FDE

توصیف ساده FDE کسیه که برای تولید محصول، به جای منتظرِ requirement موندن، خودش می‌ره وسط میدون، requirement رو کشف می‌کنه، ابهام‌ها رو کم می‌کنه، prototype یا راه‌حل production-ready می‌سازه، سیستم رو با محیط واقعی customer fit می‌کنه و فیدبک‌ها رو برمی‌گردونه به محصول.

کِی FDE کاربرد داره؟
ریشه پیدایش چنین نقشی بیشتر به شرکت‌هایی مثل Palantir برمی‌گرده.
وقتی محصول خیلی تکنیکال باشه، در عین حال، مشتری که می‌تونه کاربر درون‌سازمانی هم باشه؛ خیلی technical نیست. مثلا شرکت Palantir، محصولاتی مثل پلتفرم‌های AI/Agentic، یا ابزارهای پیچیده انترپرایز که توی صنایع سنتی مثل manufacturing، aviation، CPG و HR استفاده می‌شن داره. یعنی جایی که مشتری، مسئله بزرگ یا خیلی بزرگ داره، ولی توان فنی کافی برای تبدیل مسئله به راه‌حل نرم‌افزاری نداره.

دقت کنیم که FDE به هیچ وجه Sales Engineer یا Software Engineer معمولی یا Consultant / Professional Services نیست!
به‌طور خلاصه، FDE یک مهندس مشتری‌محوره که بین consulting، product management و software engineering می‌ایسته، ولی خروجی نهاییش باید نرم‌افزار و outcome واقعی برای مشتری باشه، نه فقط دمو، تحلیل یا توصیه.

فرق بین ownership of project و ownership of problem اینجا خیلی مهمه. آدمی که project ownership دارد ممکنه آدم سخت‌کوشی باشه، ساعات زیادی کار کنه و پروژه رو هم تموم کنه. ولی FDE باید problem ownership داشته باشه. یعنی موفقیتش با این سنجیده می‌شه که آیا مشکل مشتری واقعاً حل شده یا نه، نه اینکه PR merge شده یا ticket بسته شده.

چنین افرادی برای سازمان‌ها خیلی ارزشمندن. چه برای مصاحبه کردن چه در ارزیابی خودتون می‌تونید از ۳ بُعد بررسی کنید که به صورت کلیدواژه و خلاصه می‌گم:

بُعد Communication -> شنیدن فعال، شفاف حرف زدن، آماده بودن و executive presence

بُعد Product sense -> توضیح تصمیم‌ها، انتخاب scope درست و trade-off prioritization

بُعد Engineering -> درک عمیق از completeness، test cases، edge cases misuse cases، end-to-end delivery

نکته مهم هم اینه که FDE برای همه‌جا مناسب نیست. برای محیط‌های پویا و خلاق و پیشرفته؛ ارزش زیادی داره، چون فرد می‌تونه کنار تیم بیزینس یا عملیات بنشینه و سریع adjustment رو انجام بده. اما توی سیستم‌های سنتی، stable، heavily governed و با release process سخت‌گیرانه، این مدل اگه درست کنترل نشه می‌تونه ریسک تولید کنه.

این هم فراموش نکنیم که عنوان‌های جدید، همیشه با خودشون جوگیری رو هم میارن؛ خصوصا این روزها و با وجود AI!

#عجیب_دنیایی_شد
فورد بعد از اینکه نیروهاش رو با هوش مصنوعی جایگزین کرده بود، ۳۵۰ تا مهندس رو دوباره استخدام کرد.
معاون مهندسی فورد گفته که شرکت اشتباه فکر می‌ کرد هوش مصنوعی به‌تنهایی می‌ تونه جای مهندس‌ های باتجربه رو بگیره و همچنان ماشین‌ های با کیفیت تولید کنه.
اما نتیجه برعکس شد؛ بعد از اینکه از سال ۲۰۲۰ بیش از ۵۰۰۰ نفر رو تعدیل کرد، امسال فورد بیشتر از هر خودروساز دیگه‌ ای در آمریکا مجبور شده خودرو هاش رو فراخوان کنه.
جالبه که مدیرعامل فورد، Jim Farley، قبلاً گفته بود:
«هوش مصنوعی قراره واقعاً جای نیمی از کارمند های دفتری (white-collar) رو بگیره.»

نکشیمون پیشگوی بزرگ

در کمال پر رویی، دوباره...

اگه محتوای ارزشمندی روی سرویس تون دارین و میخواین کار کرالر هاو اسکرپر ها رو سخت تر کنید، حتما توی جستجوتون محدودیت تعداد کاراکتر بذارین، مثلا زیر ۳ کاراکتر سرچ انجام نشه. فقط اینو عاقلانه توی بکند یا BFF بذارین نه توی فرانت 😁😎😈

از لحظه ای که تصمیم بگیریم که به ارزش های واقعی خودمون واقف بشیم و روشون تمرکز کنیم، تا لحظه ای که این ارزش ها برای ما خلق ثروت کنند، خیلی مسیر کوتاه تری داریم نسبت به سایر مسیرها.

🚨 نقض جدید: اطلاعات میلیون‌ها مسافر و مشتری آژانس‌های خدمات گردشگری در معرض افشا

🔍 مجموعه‌ بزرگی حاوی بیش از 2 ترابایت از اطلاعات شرکت «فرانگر پارس سیستم» که ظاهرا چندی پیش مورد نفوذ قرار گرفته بود، در فهرست فروشندگان بانک‌های اطلاعاتی غیرمجاز مشاهده شده است. این مجموعه شامل فایل‌های داخلی، سورس‌کدها و اطلاعات هویتی، شماره تماس، ایمیل، شماره ملی، شماره پاسپورت، جزئیات سفر، رزرو و پرداخت و اطلاعات دیگری مربوط به خدمات هواپیما، قطار، اتوبوس، هتل و اقامتگاه شرکت‌های هفت اورنگ، تیک بان، هیلداسیر، رهبال آسمان، کارمانیا، اسنپ تریپ، آوان گشت، به پرواز تبریز، سپهر جم، تعطیلات، پیک خورشید، سفر ایران، علاالدین تراول، فاروس تور، نیوار پرواز ایرانیان، آسمان سپید، ساینا سیر، کاروان هوایی، آسمان پرواز و سفرهای علی فلک است.

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

✅ صحت داده‌های ارائه‌شده در بررسی نمونه‌ای تایید شد.

🆔 @leakfarsi

همین حالا تو کامنت های کانال های ارزشمند میبینم که دولوپر ها وقت بیشتری برای فلسفی فکر کردن به مسائل دارند.. و این از مزایای موج ابزارهای خوب و زیاد ai ی هست که اومده.

حس میکنم این روزها stakeholder management م به صورت چشمگیری پیشرفت داشته 😎

https://luma.com/29xj58nu
قطعا جلسه ارزشمندی میشه

مقاله بسیار مفید برای کشف این اثر :
https://incident.io/blog/automated-runbook-guide

تعریف شاخص MTTR و دسته‌بندی تیم‌ها بر اساس متدولوژی گوگل (DORA) (مستنداتی که دسته‌بندی مراجع گوگل برای سنجش تفاوت تیم‌های Elite، High و Medium را در حل بحران‌ها نشان می‌دهد)
https://agileanalytics.cloud/docs/mttr

چرا هر تیم نرم‌افزاری (حتی به ازای هر سرویس مجزا) باید Runbook داشته باشه ؟
تو دنیای امروز که سیستم‌ها ۲۴/۷ کار می‌کنن، Runbook دیگه لوکس نیست، یه ضرورته.
این Runbook چیه؟سند زنده‌ای که دقیقاً می‌گه:
🔘 سیستم چطوری کار میکنه؟
🔘 وقتی مشکلی پیش اومد چیکار کنیم؟ (Step-by-step)
🔘 وابستگی‌های سیستم چیا هستن؟
🔘 چک‌لیست‌های روزانه، هفتگی و ماهانه
🔘 راه‌حل‌های رایج خطاها و Incidentها
🔘 اطلاعات تماس افراد کلیدی و Escalation Path
🔘 حتی به تیم های مرتبط میگه endpoint هامون چین و ورودی خروجی های مورد انتظارش چیه یا لینک به مستنداتی که این ها رو نشون بده.


اهمیت Runbook برای تیم‌های نرم‌افزاری:
اثر 1- کاهش چشمگیر زمان Downtime
وقتی Incident اتفاق می‌افته، دیگه کسی سردرگم نیست که "اول کجا رو چک کنیم؟" تیم تو کمتر از ۵ دقیقه وارد Action می‌شه.
اثر 2- کاهش وابستگی به افراد خاص
- مثلا اگه یکی از اعضای کلیدی تیم مرخصی باشه یا شرکت رو ترک کنه، دانش از دست نمی‌ره.
اثر 3- Onboarding خیلی سریع‌تر
- مثلا developer یا SRE جدید تو همون هفته اول می‌تونه Incidentهای سطح متوسط رو هندل کنه.
اثر 4- Consistency در عملیات
- همه اعضای تیم به یک روش استاندارد عمل می‌کنن، نه هر کسی به سلیقه خودش.
اثر 5- بهبود کیفیت و آرامش خاطر
- وقتی بدونید همه چیز مستند شده، خواب راحت‌تری دارید!

تجربه واقعی:
تیم‌هایی که Runbook خوب دارن، MTTR (Mean Time To Recovery) شون رو تا ۵۰-۷۰٪ کاهش دادن.

پیشنهاد من:
همین امروز یه Runbook اولیه برای مهم‌ترین سرویس‌هاتون بسازید. حتی اگه ناقص باشه، بهتر از هیچی هست.
بعد به مرور کاملش کنید.از ابزارهایی مثل Notion، Confluence، Markdown تو GitHub یا GitLab Wiki می‌تونید استفاده کنید.

شما Runbook دارید؟
تو کامنت بگید تیم‌تون چقدر به مستندات عملیاتی اهمیت می‌ده؟

#DevOps #SRE #Runbook #SiteReliability #SoftwareEngineering #تیم_فنی

خوب سوباسا نداریم، چه کنیم؟ ۱۰ تا instance از ایشی زاکی بسازیم بکاریم کنار هم.

#چالش ساخت تصویر با AI

آفساید شد

گل زدن که

استراتژی امشب، اتوبوس دم دروازه پارک بشه، با روش معروف علی اصغری یا بزن زیرش فقط بزنید زیرش..

تغییرات اخیر دات‌نت ۱۱، Runtime, libraries, SDK for the AI Era (بیلد ۲۰۲۴)

در این ویدئو که قسمتی از کنفرانس BUILD 2026 است تغییرات اخیر دات‌نت ۱۱ بررسی می‌شود.
یکی از قسمت‌های جالب این تغییرات، بخش‌هایی هستند که به خاطر LLM ها به وجود آمده است. که در ادامه به چند مورد اشاره می‌کنم.

به عنوان مثال دستوراتی مثل dotnet run و dotnet build در حال حاضر با توجه به اینکه در چه کانتکستی اجرا می‌شوند، می‌توانند لاگ‌های متفاوتی تولید کنند. به طور پیش‌فرض این دستورات لاگ‌هایی تولید می‌کنند که وضعیت درونی را بیشتر توضیح می‌دهند (Live Update)، ولی این نوع لاگ‌ها برای LLM ها هم مفید نیست و هم باعث مصرف توکن بیشتر می‌شود. تکنیک جدید باعث می‌شود وقتی این دستورات توسط ابزارهای LLM استفاده می‌شوند توکن خیلی کمتری مصرف کنند!

مورد جالب دیگر تغییراتی است که توی dotnet build انجام شده که بیلدهای موازی که به خاطر agent ها بیشتر و بیشتر شده، با پرفورمنس بهتری اجرا می‌شوند.

همچنین در این جلسه در مورد Runtime Async صحبت می‌شود که بسیار فیچر مهمی است و نحوه اجرای کدهای async را از سطح کامپایلر به سطح ران‌تایم می‌برد که تغییر خیلی زیرساختی و تاثیرگذاری محسوب می‌شود، هم از لحاظ پرفورمنسی، و هم از لحاظ tooling. با این تغییر دیگر در Call Stack خبری از آن همه اطلاعاتی که به خاطر State Machine‌ به وجود آمده بود نیست و همه چیز خیلی خواناتر شده است.

🔗 ویدئو کامل را می‌توانید اینجا ببینید.

#مهران_داودی (لینکدین - بلاگ)

⁉️ برای بحث و تبادل نظر فنی در مورد این پست، نظرات خود را با ما در قسمت کامنت‌ها به اشتراک بگذارید.

کانال تلگرام:
@SoftwarePhilosophy

______

💡مرور الگوی outbox/inbox

توی نظرسنجی آخر، گزینه Inbox/Outbox Pattern رأی دوم رو آورد، بالاخره امروز مطلب رو جمع‌جور کردم. با اینکه «مرور» است ولی از نظر حجم کمی بیشتر از مطالب رایج شد (چون اصل داستان سیستم‌های توزیع شده، خیلی مبحث گسترده‌ایه و مرور یک مفهوم رایج و دم‌دستی‌اش هم نیاز به توضیح بیشتری داشت.

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

- مرور الگوی outbox/inbox
- مسئله اصلی: Dual Write Problem
- الگوی Outbox
- الگوی Inbox
- بررسی جزئی‌تر مفهوم Idempotency
- طراحی بهتر پیام‌ها
- تفاوت Domain Event و Integration Event
- روش‌های پیاده‌سازی Outbox Publisher
- ابزارها و فریم‌ورک‌های رایج برای پیاده‌سازی inbox/outbox
- مفاهیم مکمل: Poison Message، Retry و Dead Letter
- لزوم Observability و Monitoring
- کاربرد Ordering پیام‌ها
- پاک‌سازی داده‌ها
- تفاوت Outbox با Event Sourcing
- نسبت Outbox و Inbox با Saga
- چه زمانی واقعا به Inbox و Outbox نیاز داریم؟

🔗 لینک مطلب

به به یه نفر دیگه به جنبش no Estimate پیوست!