در آخرین ساعات سال ۲۰۲۵، چند خطی درباره فرصتها و تهدیدهای اکوسیستم نرمافزاری ایران در سال پیشِرو نوشتم؛ اگر دوست داشتید مطالعه کنید و نظرتون رو به اشتراک بگذارید...
امین مصباحی
سال ۲۰۲۶، فرصتها و تهدیدهای اکوسیستم نرمافزار ایران…
امروز آخرین روز سال ۲۰۲۵ است؛ و میدونم این روزها سخته؛ برای همهمون. اما همین روزهای سخته که تصمیمهای امروز ما رو معنی میده. در حالی که برای خیلیها، ذهنشون نه آرومه، نه مطمئن، نه حتی امیدوار؛ این متن رو برای دلداری یا موعظه نمینویسم. میخوام صادقانه…
❤12👏4💯2
⬇️ خروجی وب مطالب کانال
(تولید شده با استفاده از TeleScribe)
Please open Telegram to view this post
VIEW IN TELEGRAM
techafternoon.mesbahi.net
Tech Afternoon - Technical Insights & Knowledge
Archive of Tech Afternoon Telegram channel posts
❤12
به خاطر میخی، نعلی افتاد
به خاطر نعلی، اسبی افتاد
به خاطر اسبی، سواری افتاد
به خاطر سواری، جنگی شکست خورد
به خاطر شکستی، مملکتی نابود شد
و همه این ها به خاطر کسی بود که میخ را خوب نکوبیده بود
این روزها که فشار اقتصادی بخش بزرگی از جامعه را فرسوده و مستاصل کرده، طبیعیه که نگاهها به سمت دولتها، سیاستها و تصمیمهای کلان بره. اما شاید بد نباشه در کنار این نگاه، از خودمون هم بپرسیم سهم ما، بهخصوص در لایههای تخصصی و حرفهای جامعه، در شکلگیری وضع امروز چی بوده.
بحث درباره سیاست، ایدئولوژی یا نزاع و انزوای کشور، اغلب دانشی به ما اضافه نمیکنه. اما خیلی از فسادها، ناکارآمدیها و بیعدالتیها، نه در اتاقهای دربسته سیاست، بلکه از دل سیستمها و نرمافزارهایی شکل گرفته که توسط تیمهای فنی طراحی و پیادهسازی شدن. نرمافزارهایی که قرار بوده شفافیت بیاورن، اما بهدلیل تصمیمهای اشتباه، سادهسازیهای خطرناک، یا تسلیم در برابر فشار برای تحویل سریع، به ابزار پنهانکاری تبدیل شدن.
مدیر محصولی که برای راضی نگه داشتن بالادست، کنترلهای حیاتی یک فرایند روحذف میکنه. مدیر فنیای که برای گرفتن یک جایگاه، یک نرمافزار ایزوله و بیکیفیت رو بدون یکپارچگی و بدون کنترل داده تحویل میده.
تیمی که گزارشهای ناقص و سطحی تولید میکنه و همین گزارشها، مسیر سوءاستفادههای بزرگ رو هموار میکنه. در بسیاری از این موارد، نه نیت فساد وجود داشته و نه منفعت شخصی. اما نتیجه یکی بوده. باز شدن دریچهای برای اتلاف منابع، بیعدالتی و فساد. خطاهایی که «سهوی» بودن، اما آثارشون واقعی و سنگین بودن.
مسئله این نیست که همه تقصیر رو به گردن مهندسها، تحلیلگرها یا تیمهای نرمافزاری بندازیم. مسئله اینه که بپذیریم مسئولیت حرفهای، فقط نوشتن کد یا تحویل فیچر نیست. تصمیمهای فنی، حذف کنترلها، نادیده گرفتن کنترل کیفیت داده و تسلیم شدن در برابر فشار زمان و سیاست، همگی اثر اجتماعی دارن؛ حتی اگر قصدی پشتشون نباشه.
من حداقل چندین مورد رو درگیر مشاوره یا اصلاح بودم که فساد در سایه ضعف نرمافزار شکل گرفته بود و تبدیل به معضل عظیم شده بود (بعضا مبالغشون با گذشت سالها و یک صدم شدن ارزش پول، هنوز هم چشمگیر و بزرگن). اکثرا هم این فساد و سوءاستفادهها، زیر سایهی ضعفهای ساختاری همین سیستمهای جامع مالی و بازرگانی و انواع همین «سامانه»های بزرگ شکل گرفته بودن. اگر دوستانی که واقعا دغدغه داشتن و درگیر چنین مسائلی هستن، با کمال میل حاضرم جلسه آنلاینی داشته باشیم و تجربیات رو به اشتراک بگذارم.
و دوستانی که علاقه دارن خودشون تحقیق کنن شاید این کلیدواژهها بد نباشن:
- Segregation of Duties (SoD)
- End-to-End Traceability
- Audit Logging & Observability
- Data Quality Management (DQM)
- Master Data Management (MDM)
- Reference Data Management
- Single Source of Truth (SSOT)
و همیشه مهندسها با ابزارها و روشهای فنی جلو فساد رو نمیگیرن؛ بلکه با پیادهسازی روشهای به ظاهر غیر نرمافزاری در دل نرمافزارها جلو فساد رو میگیرن؛ کلیدواژههای کمکی:
- Social visibility
- Self-regulation
- Nudge theory (تلنگرهای رفتاری)
- Accountability Mechanisms
- Awareness & Participation
- Principal-Agent Theory
- Theory of Change (ToC)
- Social Norms Theory
به خاطر نعلی، اسبی افتاد
به خاطر اسبی، سواری افتاد
به خاطر سواری، جنگی شکست خورد
به خاطر شکستی، مملکتی نابود شد
و همه این ها به خاطر کسی بود که میخ را خوب نکوبیده بود
این روزها که فشار اقتصادی بخش بزرگی از جامعه را فرسوده و مستاصل کرده، طبیعیه که نگاهها به سمت دولتها، سیاستها و تصمیمهای کلان بره. اما شاید بد نباشه در کنار این نگاه، از خودمون هم بپرسیم سهم ما، بهخصوص در لایههای تخصصی و حرفهای جامعه، در شکلگیری وضع امروز چی بوده.
بحث درباره سیاست، ایدئولوژی یا نزاع و انزوای کشور، اغلب دانشی به ما اضافه نمیکنه. اما خیلی از فسادها، ناکارآمدیها و بیعدالتیها، نه در اتاقهای دربسته سیاست، بلکه از دل سیستمها و نرمافزارهایی شکل گرفته که توسط تیمهای فنی طراحی و پیادهسازی شدن. نرمافزارهایی که قرار بوده شفافیت بیاورن، اما بهدلیل تصمیمهای اشتباه، سادهسازیهای خطرناک، یا تسلیم در برابر فشار برای تحویل سریع، به ابزار پنهانکاری تبدیل شدن.
مدیر محصولی که برای راضی نگه داشتن بالادست، کنترلهای حیاتی یک فرایند روحذف میکنه. مدیر فنیای که برای گرفتن یک جایگاه، یک نرمافزار ایزوله و بیکیفیت رو بدون یکپارچگی و بدون کنترل داده تحویل میده.
تیمی که گزارشهای ناقص و سطحی تولید میکنه و همین گزارشها، مسیر سوءاستفادههای بزرگ رو هموار میکنه. در بسیاری از این موارد، نه نیت فساد وجود داشته و نه منفعت شخصی. اما نتیجه یکی بوده. باز شدن دریچهای برای اتلاف منابع، بیعدالتی و فساد. خطاهایی که «سهوی» بودن، اما آثارشون واقعی و سنگین بودن.
مسئله این نیست که همه تقصیر رو به گردن مهندسها، تحلیلگرها یا تیمهای نرمافزاری بندازیم. مسئله اینه که بپذیریم مسئولیت حرفهای، فقط نوشتن کد یا تحویل فیچر نیست. تصمیمهای فنی، حذف کنترلها، نادیده گرفتن کنترل کیفیت داده و تسلیم شدن در برابر فشار زمان و سیاست، همگی اثر اجتماعی دارن؛ حتی اگر قصدی پشتشون نباشه.
من حداقل چندین مورد رو درگیر مشاوره یا اصلاح بودم که فساد در سایه ضعف نرمافزار شکل گرفته بود و تبدیل به معضل عظیم شده بود (بعضا مبالغشون با گذشت سالها و یک صدم شدن ارزش پول، هنوز هم چشمگیر و بزرگن). اکثرا هم این فساد و سوءاستفادهها، زیر سایهی ضعفهای ساختاری همین سیستمهای جامع مالی و بازرگانی و انواع همین «سامانه»های بزرگ شکل گرفته بودن. اگر دوستانی که واقعا دغدغه داشتن و درگیر چنین مسائلی هستن، با کمال میل حاضرم جلسه آنلاینی داشته باشیم و تجربیات رو به اشتراک بگذارم.
و دوستانی که علاقه دارن خودشون تحقیق کنن شاید این کلیدواژهها بد نباشن:
- Segregation of Duties (SoD)
- End-to-End Traceability
- Audit Logging & Observability
- Data Quality Management (DQM)
- Master Data Management (MDM)
- Reference Data Management
- Single Source of Truth (SSOT)
و همیشه مهندسها با ابزارها و روشهای فنی جلو فساد رو نمیگیرن؛ بلکه با پیادهسازی روشهای به ظاهر غیر نرمافزاری در دل نرمافزارها جلو فساد رو میگیرن؛ کلیدواژههای کمکی:
- Social visibility
- Self-regulation
- Nudge theory (تلنگرهای رفتاری)
- Accountability Mechanisms
- Awareness & Participation
- Principal-Agent Theory
- Theory of Change (ToC)
- Social Norms Theory
❤18👎7👍4💯1😐1
وقتی مهندسی شریک رنج میشه
در حالی این مطلب رو مینویسم که حدود یک هفته است که ارتباط ایران با اینترنت قطع شده و اونچه که به بیرون میاد ترکیب آشفتهای از خبر و شایعه است؛ اخباری که در خوشبینانهترین حالتش، چیزی جز صدای درد و رنج و فقدان نیست…
حتی در مورد انتشار این مطلب مردد هستم...
ادامه
در حالی این مطلب رو مینویسم که حدود یک هفته است که ارتباط ایران با اینترنت قطع شده و اونچه که به بیرون میاد ترکیب آشفتهای از خبر و شایعه است؛ اخباری که در خوشبینانهترین حالتش، چیزی جز صدای درد و رنج و فقدان نیست…
حتی در مورد انتشار این مطلب مردد هستم...
ادامه
امین مصباحی
وقتی مهندسی شریک رنج میشه
در حالی این مطلب رو مینویسم که حدود یک هفته است که ارتباط ایران با اینترنت قطع شده و اونچه که به بیرون میاد ترکیب آشفتهای از خبر و شایعه است؛ اخباری که در خوشبینانهترین حالتش، چیزی جز صدای درد و رنج و فقدان نیست…حتی در مورد انتشار این مطلب مردد هستم؛…
💔23
بچهها قرار نیست همه برنامهنویس بشن، ولی باید مسئله حل کنن!
مدتها بود که دوست داشتم در مورد دلایل اهمیت یادگیری برنامهنویسی برای کودکان بنویسم؛ اینکه هیچ ربطی به شغل آیندهی کودک نداره و مهارتهای پشتش باید شکل بگیره که اونها مهم هستن. و فعلا برنامهنویسی یکی از بهترین روشها برای یادگیری اون مهارتها به شمار میان.
این روزها که وضعیت ایران رو میبینم تصور میکنم راه نجاتی جز نسل بعدی برای آینده ایران نیست؛ لذا چند خطی رو در این مورد نوشتم که اگر علاقهمند بودید بخونید و نظرتون رو بگید.
لینک مطلب
مدتها بود که دوست داشتم در مورد دلایل اهمیت یادگیری برنامهنویسی برای کودکان بنویسم؛ اینکه هیچ ربطی به شغل آیندهی کودک نداره و مهارتهای پشتش باید شکل بگیره که اونها مهم هستن. و فعلا برنامهنویسی یکی از بهترین روشها برای یادگیری اون مهارتها به شمار میان.
این روزها که وضعیت ایران رو میبینم تصور میکنم راه نجاتی جز نسل بعدی برای آینده ایران نیست؛ لذا چند خطی رو در این مورد نوشتم که اگر علاقهمند بودید بخونید و نظرتون رو بگید.
لینک مطلب
امین مصباحی
بچهها قرار نیست همه برنامهنویس بشن، ولی باید مسئله حل کنن!
فراتر از حرف و شعار، اگر واقعا باور داشته باشیم که آینده هر کشوری و به تبع اون آینده ایران، به کیفیت نسل بعدی گره خورده، ناچاریم روی یک موضوع مکث کنیم: توانایی حل مسئله. نه صرفا سواد، نه مدرک، نه حتی مهارت شغلی مشخص؛ بلکه اینکه انسان بتونه یک مسئله پیچیده…
❤14👍4👏4💯1
سلام؛
اگر امروز چند میلیون به سادگی فایلهاشون رو روی اینترنت آپلود میکنن و از هر نقطهی دنیا با یه URL ساده بهش دسترسی دارن، بخش بزرگی از این سادگی مدیون معماریایه که Amazon S3 حدود دو دهه پیش طراحی کرد.
تقریباً اکثر آبجکتاستوریجهای مطرح دنیا، چه از سمت Amazon، Microsoft، Google و چه نمونههای داخلی مثل آروان یا ستون، با API سازگار با S3 کار میکنن یا عملاً از همون مدل الهام گرفتهان.
ایده ساده ولی عمیق:
به جای فایلسیستم سنتی با سلسلهمراتب پیچیده، یک مدل object-based با namespace تخت، شناسه یکتا، متادیتا، و از پایه و اساس طراحیشده برای مقیاسپذیری افقی. نتیجه؟ ذخیرهسازی massively scalable با durability بالا و هزینه منطقی.
پروژههای متنباز مثل Ceph، MinIO و RustFS هم دقیقاً توی همین فضا رشد کردن و اکوسیستم S3-compatible رو تقویت کردن. این یعنی S3 فقط یک سرویس نبود؛ بلکه اینقدر خوب بود که تبدیل به یک قرارداد معماری شد.
اگر به طراحی سیستمهای توزیعشده، trade-off بین consistency و availability، یا تصمیمهای اولیهای که بعدها تبدیل به استاندارد صنعت شدند علاقه دارین، این گفتوگو توی کانال The Pragmatic Engineer از زاویه مهندسی و معماری نکات ارزشمندی داره. مصاحبه دقیق و فنی با معاون تکنولوژی AWS، خانم مایلان تامسون.
پیشنهاد میکنم اگر به زیرساخت و معماری علاقه دارید، بخشی از آخر هفته رو به دیدنش اختصاص بدید.
📢 در ضمن برای انتخاب موضوع مطالب آتی کانال خوشحال میشم پیشنهادهاتون رو کامنت کنید؛ اگر چیزی در موردشون بدونم یا تجربهای داشته باشم، حتمن در اولویت خواهند بود 😊
اگر امروز چند میلیون به سادگی فایلهاشون رو روی اینترنت آپلود میکنن و از هر نقطهی دنیا با یه URL ساده بهش دسترسی دارن، بخش بزرگی از این سادگی مدیون معماریایه که Amazon S3 حدود دو دهه پیش طراحی کرد.
تقریباً اکثر آبجکتاستوریجهای مطرح دنیا، چه از سمت Amazon، Microsoft، Google و چه نمونههای داخلی مثل آروان یا ستون، با API سازگار با S3 کار میکنن یا عملاً از همون مدل الهام گرفتهان.
ایده ساده ولی عمیق:
به جای فایلسیستم سنتی با سلسلهمراتب پیچیده، یک مدل object-based با namespace تخت، شناسه یکتا، متادیتا، و از پایه و اساس طراحیشده برای مقیاسپذیری افقی. نتیجه؟ ذخیرهسازی massively scalable با durability بالا و هزینه منطقی.
پروژههای متنباز مثل Ceph، MinIO و RustFS هم دقیقاً توی همین فضا رشد کردن و اکوسیستم S3-compatible رو تقویت کردن. این یعنی S3 فقط یک سرویس نبود؛ بلکه اینقدر خوب بود که تبدیل به یک قرارداد معماری شد.
اگر به طراحی سیستمهای توزیعشده، trade-off بین consistency و availability، یا تصمیمهای اولیهای که بعدها تبدیل به استاندارد صنعت شدند علاقه دارین، این گفتوگو توی کانال The Pragmatic Engineer از زاویه مهندسی و معماری نکات ارزشمندی داره. مصاحبه دقیق و فنی با معاون تکنولوژی AWS، خانم مایلان تامسون.
پیشنهاد میکنم اگر به زیرساخت و معماری علاقه دارید، بخشی از آخر هفته رو به دیدنش اختصاص بدید.
📢 در ضمن برای انتخاب موضوع مطالب آتی کانال خوشحال میشم پیشنهادهاتون رو کامنت کنید؛ اگر چیزی در موردشون بدونم یا تجربهای داشته باشم، حتمن در اولویت خواهند بود 😊
tech-afternoon
بچهها قرار نیست همه برنامهنویس بشن، ولی باید مسئله حل کنن! مدتها بود که دوست داشتم در مورد دلایل اهمیت یادگیری برنامهنویسی برای کودکان بنویسم؛ اینکه هیچ ربطی به شغل آیندهی کودک نداره و مهارتهای پشتش باید شکل بگیره که اونها مهم هستن. و فعلا برنامهنویسی…
تفکر محاسباتی در بزرگسالی؛ بازسازی ظرفیت تحلیل و حل مسئله!
این مطلب، در ادامه یادداشتی است که در مورد مهارت «حل مسئله» برای کودکان نوشته بودم؛ منتها برای بزرگسالها.
مخاطب این مطلب: بعضی افرادی که ظاهرا در نقشهای فنی یا مدیریتی فعالیت میکنن، ولی به مرور از تمرین واقعی مسئلهحلکردن فاصله میگیرن.
مدیرهایی که بیشتر وقتشون صرف هماهنگی و جلسه میشه.
توسعهدهندههایی که در چرخه کارهای تکراری و نگهداری سیستمها محاصره شدن.
افرادی که تصمیم میگیرن، اما کمتر ساختار مسئله رو باز میکنن.
و شاید هر کسی که به این موضوع علاقهمند باشه...
مثل همیشه خوشحال میشم نظر یا تجربهتون رو بدونم 😊
این مطلب، در ادامه یادداشتی است که در مورد مهارت «حل مسئله» برای کودکان نوشته بودم؛ منتها برای بزرگسالها.
مخاطب این مطلب: بعضی افرادی که ظاهرا در نقشهای فنی یا مدیریتی فعالیت میکنن، ولی به مرور از تمرین واقعی مسئلهحلکردن فاصله میگیرن.
مدیرهایی که بیشتر وقتشون صرف هماهنگی و جلسه میشه.
توسعهدهندههایی که در چرخه کارهای تکراری و نگهداری سیستمها محاصره شدن.
افرادی که تصمیم میگیرن، اما کمتر ساختار مسئله رو باز میکنن.
و شاید هر کسی که به این موضوع علاقهمند باشه...
مثل همیشه خوشحال میشم نظر یا تجربهتون رو بدونم 😊
امین مصباحی
تفکر محاسباتی در بزرگسالی؛ بازسازی ظرفیت تحلیل
یکی از سوءبرداشتهای رایج اینه که «تفکر محاسباتی» مهارتیه مربوط به آموزش پایه و کودکان. در حالی که از منظر علوم شناختی، این مهارت بیش ازاینکه یک موضوع آموزشی باشه، یک الگوی پردازش اطلاعات و تصمیمگیریه که در تمام طول عمر میتونه تقویت یا تضعیف بشه. تفکر محاسباتی…
❤10
گاهی فکر میکنیم «سیستم ما که دو تا سرویس بیشتر نیست» یا «فعلا مونولیت هستیم، پس traceability فعلا اهمیتی نداره و هر وقت بزرگتر شد درستش میکنیم». ولی واقعیت اینه که زنجیرهی callها از همون روز اول وجود داره. حتی اگر فقط یک API به یک دیتابیس وصل باشه. مسئله این نیست که microservice داریم یا نه.
مسئله اینه که وقتی یک درخواست وارد سیستم میشه، آیا میتونیم مسیرش رو از ابتدا تا انتها ببینیم یا نه؟
حالا Traceability یعنی چه؟
یعنی بتونیم به این سوال ساده جواب بدهیم: این درخواست دقیقا از کجا اومده، از چه سرویسهایی عبور کرده، کجا کند شده، و چرا خطا داده؟
توی معماری microservice این موضوع حیاتیه، چون زنجیرهی callها طولانی و توزیعشده است. ولی حتی توی یک سیستم کوچک هم اگر این قابلیت رو نداشته باشیم، debugging زمانبر، و به حدس و گمان تبدیل میشه.
چرا حتی برای سیستمهای کوچک هم مهمه؟
برخی تصور میکنن Distributed Tracing مخصوص سیستمهای بزرگه. اما به تجربه:
- حتی یک سیستم سهلایه ساده هم بدون trace خوب، در زمان بروز مشکل، میتونه تبدیل به تاریکی مطلق بشه.
- وقتی یک feature ساده کند میشه، اگر trace نداشته باشی، شروع میکنی لاگها رو grep کردن و فرضیه ساختن.
- وقتی فرد جدیدی به تیم اضافه میشه، داشتن trace خوب، عملا بهترین مستند معماری زنده است.
پس Traceability باعث میشه:
- فرایند debugging از «حدس» به «مشاهده» تبدیل بشه
- به مرور blame culture توی تیم کمتر بشه، چون مسیر واقعی قابل دیدنه
- عملا bottleneckها خیلی سریعتر شناسایی بشن
- وابستگیها شفاف باشن
سه ستون اصلی Traceability
۱: اصل Context Propagation
یعنی باید context هر درخواست همراهش حرکت کنه. Trace ID و Span ID باید از سرویس A به B و C منتقل بشن. و اگر این زنجیره قطع بشه، عملا trace بیارزش میشه. استاندارد رایج امروز: W3C Trace Context. و این یعنی هدرهای استاندارد برای انتقال trace بین سرویسها.
۲: اصل Correlation بین Log و Trace
داشتن trace بدون لاگ بیفایده است. و داشتن لاگ بدون trace هم ناقصه. هر log مهم باید شامل:
trace_id
span_id
باشه تا بتونی از یک error log مستقیم بپری روی trace کامل اون درخواست. Structured logging اینجا حیاتیه (گرچه همه جا مهمه نه فقط توی traceability و متن آزاد و غیرساختیافته توی سیستمهای جدی قابل دفاع نیست.)
۳: طراحی درست Spanها
نام spanها باید پایدار و کمکاردینال باشه. به جای اینکه IDهای متغیر رو داخل نام span بگذاریم، اونها رو به صورت attribute باید ثبت کرد.
مثلا:
درست: HTTP POST /employee/{id}
غلط: HTTP POST /employee/1037685
اگر این موضوع رعایت نشه، هزینه و performance ابزارهای observability صدمه میبینه.
توی سیستمهای Async و Message-based
خیلی وقتها فکر میکنیم tracing فقط مربوط به HTTP است. ولی توی سیستمهای event-driven اگر context رو داخل header پیام منتقل نکنی، زنجیره عملا قطع میشه. برای publish و consume هم برای هر پیام باید span جداگانه وجود داشته باشه. وگرنه نمیفهمی این job واقعا نتیجهی کدوم درخواست بوده.
چند Best Practice عملی
- از یک استاندارد واحد استفاده کن. OpenTelemetry امروز انتخاب منطقیایه.
- سعی کنید sampling هوشمند داشته باشید. همه چیز رو صددرصد نگه داشتن، راهکار نیست.
- به هیچ وجه PII رو داخل trace و log نریزید. اگر لازمه، hash یا mask کنید (به صورت کلی complience رو جدی بگیرید).
- حتمن naming convention مشخص برای سرویسها و spanها داشته باشید.
- موضوع dependencyهای بیرونی مثل DB و external APIها رو حتما داخل trace بیارید.
- فقط errorها رو log نکنید، داخل span هم record کنید.
موضوع Traceability فقط ابزار نیست، فرهنگه! اگر تیم به این موضوع باور نداشته باشه، ابزار به تنهایی کمکی نمیکنه. باید در code reviewها به propagation دقت بشه. باید logging استاندارد enforce بشه. و باید observability contract بین تیمها تعریف بشه (توی سازمانهای بزرگتر وظیفه تیم اینتگریشن یا پلتفرم است)
جمعبندی: داستان Traceability چیزی نیست که «وقتی بزرگ شدیم» اضافه کنیم. این یکی از اون قابلیتهاییه که اگر از روز اول درست پیاده بشه:
- هزینهی debugging به شدت کاهش پیدا میکنه
- معماری شفافتر میشه
- رشد سیستم قابل کنترلتر میشه
- و در زمان بحران، تیم به جای سردرگمی، تصویر واضحی از واقعیت داره
سیستم بدون trace مثل شهریه که دوربین کنترل ترافیک نداره. شاید در روزهای آروم و تعطیلات مشکلی حس نشه. ولی در اولین روز پرکار و شلوغ، تازه میفهمی چی کم بوده.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍8
🪞روز مهندس، و داستان جناب هانسکریستیناندرسون که هنوز تمام نشده!
قرن ۱۹ میلادی، نویسنده سرشناس دانمارکی، در کنار داستانهای به ظاهر سادهای مثل دختر کبریتفروش یا جوجهاردک زشت، داستان لباس جدید پادشاه رو نوشت که احتمالا اکثر ما یا کتابش رو در کودکی خوندیم، یا کارتونش رو تماشا کردیم.
فکر میکنم بد نباشه جامعه مهندسی نرمافزار، گاهی جلو آیینه بایسته و ببینه که چقدر لُخت است! توی قصه «پادشاه لخت»، مشکل فقط یک پادشاه سادهلوح نبود. مسئله، یک اکوسیستم کامل بود:
- خیاطهای دروغین
- درباریان تأییدکننده
- جمعیتی که جرئت پرسیدن نداشت
و فقط یک کودک بود که گفت: چیزی تنش نیست!
اگر بخوایم صادق باشیم، ما هم در اکوسیستم نرمافزار، کم از اون دربار نداریم. و چقدر برای مناسب ظاهر شدن، نیاز به یادگیری و تلاش مضاعف داریم. خیاطهای دروغین امروز همیشه شیادهای بیرونی نیستن.
گاهی در لباس لیدر فنی ظاهر میشن که بدون threat model و بدون طراحی امنیتی، سیستم رو «production-ready» اعلام میکنن.
گاهی در قامت تیم محصول که زمان تحویل را بالاتر از امنیت و کیفیت مینشونن.
گاهی در نقش مدیر که بودجه آموزش، معماری، یا امنیت رو هزینه اضافی میدونن.
و گاهی هم در قامت مهندس باتجربهای که سالهاست چیز جدیدی یاد نگرفته ولی همچنان با اعتمادبهنفس حرف میزنه.
و درباریان؟
ما وقتی بدون خوندن دقیق PR رو تأیید میکنیم.
وقتی postmortem واقعی نمینویسیم.
وقتی ضعف امنیتی رو میدونیم ولی میگیم “بعداً درستش میکنیم”.
وقتی outage رو «اتفاق طبیعی» جا میزنیم.
مسئله این نیست که هک شدیم یا نشدیم. کند یا ناپایدار هستیم یا نه!
مسئله اینه که آیا اصول مهندسی رو جدی گرفتهایم یا نه.
اما سؤال جدی اینه:
چند تیم واقعاً اینها رو در عمل اجرا میکنند، نه فقط در رزومه؟
اگر بخواهیم جلوی آینه بایستیم، شاید بهتر باشد به جای شعار، این چکلیست رو از خودمون بپرسیم:
آیا ما اینها رو داریم؟
- اصول Security by Design، نه Security after Incident
- مفاهیم Threat Modeling مستند
- ساختار Secure SDLC واقعی، نه اسلاید پاورپوینت
- مکانیزمهای observability جدی
- ساختار Data Governance مشخص
- طبقهبندی داده و سیاست retention
- مدیریت دسترسی مبتنی بر اصل Least Privilege یا زیروتراست
- اصول Software Composition Analysis و مدیریت dependency
- ساختار Incident response plan تمرینشده
و...
اگر اینها نیست، ما فقط امیدواریم، مهندسی نمیکنیم.
روز مهندس شاید بیشتر از اونکه تبریک بخواد، احتیاج به صداقت داره.
صداقت با خودمون.
شاید وقتش باشه به جای تبریکهای شاعرانه، هرکدوممون یک ضعف مهندسی رو در تیممون جدی اصلاح کنیم. (جلو آینه بایستیم و لخت بودنمون رو ببینیم!)
لباس، با آرزو دوخته نمیشه.
با استاندارد، تمرین و مسئولیتپذیری دوخته میشه.
قرن ۱۹ میلادی، نویسنده سرشناس دانمارکی، در کنار داستانهای به ظاهر سادهای مثل دختر کبریتفروش یا جوجهاردک زشت، داستان لباس جدید پادشاه رو نوشت که احتمالا اکثر ما یا کتابش رو در کودکی خوندیم، یا کارتونش رو تماشا کردیم.
فکر میکنم بد نباشه جامعه مهندسی نرمافزار، گاهی جلو آیینه بایسته و ببینه که چقدر لُخت است! توی قصه «پادشاه لخت»، مشکل فقط یک پادشاه سادهلوح نبود. مسئله، یک اکوسیستم کامل بود:
- خیاطهای دروغین
- درباریان تأییدکننده
- جمعیتی که جرئت پرسیدن نداشت
و فقط یک کودک بود که گفت: چیزی تنش نیست!
اگر بخوایم صادق باشیم، ما هم در اکوسیستم نرمافزار، کم از اون دربار نداریم. و چقدر برای مناسب ظاهر شدن، نیاز به یادگیری و تلاش مضاعف داریم. خیاطهای دروغین امروز همیشه شیادهای بیرونی نیستن.
گاهی در لباس لیدر فنی ظاهر میشن که بدون threat model و بدون طراحی امنیتی، سیستم رو «production-ready» اعلام میکنن.
گاهی در قامت تیم محصول که زمان تحویل را بالاتر از امنیت و کیفیت مینشونن.
گاهی در نقش مدیر که بودجه آموزش، معماری، یا امنیت رو هزینه اضافی میدونن.
و گاهی هم در قامت مهندس باتجربهای که سالهاست چیز جدیدی یاد نگرفته ولی همچنان با اعتمادبهنفس حرف میزنه.
و درباریان؟
ما وقتی بدون خوندن دقیق PR رو تأیید میکنیم.
وقتی postmortem واقعی نمینویسیم.
وقتی ضعف امنیتی رو میدونیم ولی میگیم “بعداً درستش میکنیم”.
وقتی outage رو «اتفاق طبیعی» جا میزنیم.
مسئله این نیست که هک شدیم یا نشدیم. کند یا ناپایدار هستیم یا نه!
مسئله اینه که آیا اصول مهندسی رو جدی گرفتهایم یا نه.
من قبلاً دو اپیزود درباره تولید امن نرمافزار ساختم. درباره: SSDLC, STRIDE, Shift-left, SAST, DAST, IAST, RASP, SCA
در مورد بدهی فنی هم یه ویدیو کوتاه
اما سؤال جدی اینه:
چند تیم واقعاً اینها رو در عمل اجرا میکنند، نه فقط در رزومه؟
اگر بخواهیم جلوی آینه بایستیم، شاید بهتر باشد به جای شعار، این چکلیست رو از خودمون بپرسیم:
آیا ما اینها رو داریم؟
- اصول Security by Design، نه Security after Incident
- مفاهیم Threat Modeling مستند
- ساختار Secure SDLC واقعی، نه اسلاید پاورپوینت
- مکانیزمهای observability جدی
- ساختار Data Governance مشخص
- طبقهبندی داده و سیاست retention
- مدیریت دسترسی مبتنی بر اصل Least Privilege یا زیروتراست
- اصول Software Composition Analysis و مدیریت dependency
- ساختار Incident response plan تمرینشده
و...
اگر اینها نیست، ما فقط امیدواریم، مهندسی نمیکنیم.
روز مهندس شاید بیشتر از اونکه تبریک بخواد، احتیاج به صداقت داره.
صداقت با خودمون.
شاید وقتش باشه به جای تبریکهای شاعرانه، هرکدوممون یک ضعف مهندسی رو در تیممون جدی اصلاح کنیم. (جلو آینه بایستیم و لخت بودنمون رو ببینیم!)
لباس، با آرزو دوخته نمیشه.
با استاندارد، تمرین و مسئولیتپذیری دوخته میشه.
منظورم از اکوسیستم، فقط گروه خاصی نیست که ربطش بدیم به وقایع سیاسی و اجتماعی کنونی و بگیم اونا که از ما نیستن یا رفتنیاند و بعدش درستش میشه و از خودمون صلب مسئولیت کنیم.
از استارتاپهای متعدد خصوصی که هک شدن، تا بانک و سازمانی که با هک شدن دادههاش نابود شد و از روی پیامکها موجودی مردم رو بازسازی! کردن! تا نرمافزار دانشگاه تا... همه و همه گواهی بر لُختی جامعه نرم افزاریه!
❤19👍4🔥3👏1💯1
با فراگیر شدن GenAI، تبِ چیزی که بعدتر وایبکدینگ اسم گرفت هم روز به روز داغتر شد. لزوم ساختار دادن به تعامل توسعهدهنده و مدل زبانی، برای همین به تدریج فایلهای prompts.md و بعدتر instructions.md و پشتیبانی از tools و MCPها به گیتهاب کوپالوت اومدن (قبلا در مورد همه اینها توی کانال نوشتهام). ولی همونطور که مدلها پیشرفت کردن، ابزارها و ساختارهایی که کمک میکردن تا مدلها رو بهتر به خدمتِ ساختاردهی توسعه دربیاریم هم پیشرفت کردن. مثلا فایلهای prompts.md با وجود کاربردی بودنشون، خیلی زود محدودیتهاشون رو نشون دادن، پس پشتیبانی از instructions.md و tools هم اضافه شد. ولی جای چند تا چیز خالی بود:
- دانش دائمی، به خصوص، و تکرارشونده
- پشتیبانی از ورژن
- فقط فایل markdown نباشه، بشه بهش مثال و منبع و... هم معرفی کرد. عین دوره آموزشی؛ ولی خیلی سادهتر و سرراستتر از RAG ساختن
پس برای همین skills به وجود اومد، ساختاری که مهارت به خصوص، مثل دانش مرور کدها برای عدم تخطی از اصول امنیتی مورد توافق تیم/سازمان. یا حتی مهارت ایجاد تغییرات لازم برای استفاده از ORM جدید به جای ORM فعلی یا... ولی اینبار:
- باید یک فولدر باشه
- حتماً فایل SKILL.md داشته باشه
- میتونه همراهش اسکریپت، مثال، الگو، منابع آموزشی، و تعریف workflow داشته باشه
- هدفش اینه که دانش تکرارشونده و procedural رو در قالبی قابل اشتراک و بارگذاری تعریف کنه
- این یعنی Skills از نظر قابلیتهای عملیاتی و قابل استفاده مجدد خیلی جلوتر از فایلهای markdown ساده هست
.github\skills
.agents\skills
.claude\skills
ولی Skills یک استاندارد متنباز و جامعهمحوره که با مجوز Apache 2.0 توسط agentskills.io در دسترس عموم قرار داده شده؛ و چه Claude Code چه خانواده GitHub Copilot (plugin, CLI, SDK) و... ازش پشتیبانی میکنن و marketplaceهای به اشتراکگذاری skillها که زیاد شدن. به بیان خیلی ساده، Skill همون چیزیه که ما دوباره و دوباره میخوایم هوش مصنوعی انجام بده، ولی این بار در قالب یک بسته تعریفشده، نه پرامپت دستی.
🔧 ترکیب قابلیتها: میتونین چند Skill رو با هم ترکیب کنین تا workflowهای پیچیدهتر رو پوشش بدین.
📦 صرفهجویی در زمان و خطا: چون مراحل کاری، چکلیستها و اسکریپتها از قبل تعریف شدهان، نتایج قابل پیشبینیتر هستن.
🧠 مثال کاربردی:
فرض کنید هر بار که یک Pull Request در گیتهاب ایجاد میکنین، باید این کارها رو انجام بدید:
- اول چک کنه تیکت مرتبط با PR هر چی خواسته، توی تغییرات اومده و Acceptance criteria ها جا نیوفتاده از دست توسعهدهنده
- چکلیست امنیتی رو اجرا کنه
- تستهای یکپارچهسازی رو بررسی کنه
- معیارهای کیفی رو حساب کنه
- خروجی رو گزارش بده
به جای اینکه هر بار با پرامپت اینها را توضیح بدید، میتونید یک Skill بسازید با یک فولدر شامل: .github/skills/pr-review/SKILL.md و در ضمن فایلهای مثال و توضیح رو هم توی همین پوشه قرار بدید و توی فایل SKILL.md بگید ازشون استفاده کنه برای یاد گرفتن.
مثلا بنویسید:
- چه زمانی این Skill باید فعال بشه
- چه مراحلی رو باید انجام بده
- چه منابع یا چکلیستهایی همراه داشته باشه
بعدش هر ابزاری که از Agent Skills پشتیبانی کنه، مثل GitHub Copilot CLI یا Copilot coding agent، وقتی prompt مرتبط رو ببینه، این Skill رو بارگذاری و اجرا میکنه، بدون اینکه شما دوباره توضیح بدید.
🚀 چه چیزهایی میتونن به Skill تبدیل بشن؟
هر چیزی که تکرارشونده یا قابل استانداردسازی باشه:
- الگوی نوشتن مستندات (RFC، Arch review، design doc)
- چکلیستهای Code Review
- ایجاد template برای Issue و Task
- گامهای یونیت تست، تست یکپارچهسازی یا تست امنیت
- متدهای اتوماسیون workflowهای سازمانی
یا مثالهای اینجا یا اینجا یا اینجا
وقتی یک Skill تعریف میکنید، ابزارهای مختلفی که از استاندارد پشتیبانی میکنن میتونن ازش بهرهمند بشن و این یعنی دانش تیمی یا سازمانی رو قابل استفاده مجدد میکنین. Agent Skills داره تبدیل به استاندارد رایج برای تعریف تواناییهای هوش مصنوعی میشه. این یعنی دیگه نیاز نیست هر بار از صفر به هوش مصنوعی بگید چه کار کنه. شما میتونید مراحل، چکلیستها، اسکریپتها و دانش خودتون رو در قالب Skill تعریف کنین و ابزارهای مختلف مثل Copilot اونها را به صورت قابل استفاده مجدد بارگذاری کنن. این کار باعث میشه خروجیهای هوش مصنوعی قابل پیشبینیتر، استانداردتر و کمتر وابسته به پرامپت دستی باشه.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤6👍5
بچههای معصومی که پرپر شدند، آرزو داشتن تا بزرگ بشن، موفق بشن و بهترینِ خودشون باشن...
این بچهها آرزو داشتن تا به اندازهی توانشون موفق بشن، برای خودشون، خانوادهشون، شهرشون یا کشورشون مفید باشن. اون پسربچهای که برای آخرین بار با مادرش خداحافظی کرد، رفت مدرسه، تا شاد بودن، یاد گرفتن، پیشرفت کردن رو با خودش برگردونه و مادرش رو خوشحال کنه. نفرین بر جنگ، نفرین بر کسی که دستور داد، همراهی کرد و نهایتا ماشهی اون ۲ موشک نحس رو کشید تا این داغ به دل انسانیت بشینه.
روزهای تلخی گذشت، و خدا میدونه سایهی نحس جنگ تا چه زمانی تن ایران رو رنجور و زخمی خواهد کرد؛ و بعد از آخرین شلیک، چهرهی کشور ما چه شکلی خواهد داشت...
مدرسه، پالایشگاه، فرودگاه و هر جایی ویران بشه دردناکه، ولی درد بزرگتر، جهل و فقر فکری است که این روزها کالای رایجی شده؛ و «خِرَد» متاعی کمیاب. از اونهایی که موشک میفرستن تا اونهایی که برای اصابتش کف میزنن. پس، باید نوشت، یاد داد، تلاش کرد؛ بیش از گذشته... به حد بضاعت؛ این تنها کاریه که شاید بلد باشیم یا از دستمون ساخته باشه. به نیت تکتک بچههایی که دوست داشتن یاد بگیرن، و بهترینِ خودشون باشن. برای تکتک بچههایی که کشورشون، خانوادهشون، زبانشون، و «زندگی» رو دوست داشتن.
یادمون نره، این کشور حملهی مغول رو هم از سر گذروند، تاریخ گواهی میده که اون زمان هم عدهای که بضاعت فکری و ارادهی عملی نداشتن، برای حمله به خاک کشور شادی کردن، ولی ما امروز اسم سعدی رو میدونیم، و کمتر کسی نام کسانی رو که از سر جهل و طمع، زهر افعی رو دوای زخم کشور تجویز کردن به یاد داره...
برای همه آرزوی سلامتی و امنیت دارم، خصوصا برای تکتک اعضای کادر درمان، نیروهای امدادی، و بچههایی که قراره دنیا رو به جای بهتری تبدیل کنند... 🖤😔🌱
این بچهها آرزو داشتن تا به اندازهی توانشون موفق بشن، برای خودشون، خانوادهشون، شهرشون یا کشورشون مفید باشن. اون پسربچهای که برای آخرین بار با مادرش خداحافظی کرد، رفت مدرسه، تا شاد بودن، یاد گرفتن، پیشرفت کردن رو با خودش برگردونه و مادرش رو خوشحال کنه. نفرین بر جنگ، نفرین بر کسی که دستور داد، همراهی کرد و نهایتا ماشهی اون ۲ موشک نحس رو کشید تا این داغ به دل انسانیت بشینه.
روزهای تلخی گذشت، و خدا میدونه سایهی نحس جنگ تا چه زمانی تن ایران رو رنجور و زخمی خواهد کرد؛ و بعد از آخرین شلیک، چهرهی کشور ما چه شکلی خواهد داشت...
مدرسه، پالایشگاه، فرودگاه و هر جایی ویران بشه دردناکه، ولی درد بزرگتر، جهل و فقر فکری است که این روزها کالای رایجی شده؛ و «خِرَد» متاعی کمیاب. از اونهایی که موشک میفرستن تا اونهایی که برای اصابتش کف میزنن. پس، باید نوشت، یاد داد، تلاش کرد؛ بیش از گذشته... به حد بضاعت؛ این تنها کاریه که شاید بلد باشیم یا از دستمون ساخته باشه. به نیت تکتک بچههایی که دوست داشتن یاد بگیرن، و بهترینِ خودشون باشن. برای تکتک بچههایی که کشورشون، خانوادهشون، زبانشون، و «زندگی» رو دوست داشتن.
یادمون نره، این کشور حملهی مغول رو هم از سر گذروند، تاریخ گواهی میده که اون زمان هم عدهای که بضاعت فکری و ارادهی عملی نداشتن، برای حمله به خاک کشور شادی کردن، ولی ما امروز اسم سعدی رو میدونیم، و کمتر کسی نام کسانی رو که از سر جهل و طمع، زهر افعی رو دوای زخم کشور تجویز کردن به یاد داره...
برای همه آرزوی سلامتی و امنیت دارم، خصوصا برای تکتک اعضای کادر درمان، نیروهای امدادی، و بچههایی که قراره دنیا رو به جای بهتری تبدیل کنند... 🖤😔🌱
👎16💔14❤2👍2