Learning With M

بزارم اینجا بمونه به یادگار:

هوش، توهمی از تسلطه.

رفرنس: خودم
منبع برای مطالعه: تفکر سریع و کند، دنیل کنمن

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

اگر چهارچوب‌های اسم و رسم‌دار چابکی را مرور کنید، خواهید دید که همگی شیوه‌ای یکسان را برای برگزاری این جلسه پیشنهاد کرده‌اند:

🔹در آغاز: اعضای تیم با همکاری یک تسهیل‌گر شروع به نوشتن اتفاقات و اقداماتی می‌کنند که به گمان آنها خوب و خوشحال‌کننده بوده‌اند و یا بد و آزاردهنده.

🔹در میانه: سعی می‌شود به شکلی دموکراتیک، برخی از موضوعات مطروحه، انتخاب و به بحث گذاشته شوند.

🔹سرانجام: سعی می‌شود تا بر پایه توافقی جمعی (مبتنی بر آرای اکثریت) برخی اقدامات که به گمان اعضای تیم باعث بهبود و رضایت می‌شود، انتخاب شوند و همگی متعهد به رعایت آنها شوند.

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

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

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

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

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

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

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

نکن همکار عزیز ! نکن برادر من! نکن خواهر من ! 👍

#روز_نوشت
#طنز

از کانال محمد عزیز (@icodenext):

🌀 ساکنان جزیره فرم رو درک کرده بودند، اما محتوی رو نه.

💥 امروز صبح، یهویی یاد آنتی پترن کلندر کدر افتادم، و خوب داستان جذابی داره این آنتی پترن. یهویی نشستم پست میکروفن و رکورد کردم.

01:20 World War II
02:30 Melanesia
03:25 Cargo Cult
07:35 Cargo Cult Programming
09:00 Calendar Coder Anti-Pattern

امیدوارم مفید بوده باشه. ببخشید دیگه باید صدای من رو تحمل کنید. ❤️

ویس در کست باکس هم آپلود شد.

https://castbox.fm/episode/Cargo-Cult-Programming-id5362393-id773612501

https://t.me/icodenext

سلام،
عزیزانی که توی این نظرسنجی شرکت نکردند، ممنون میشم امروز شرکت کنند.
چند روز دیگه نظرسنجی بسته میشه و من میخوام جمعبندی کنم و گزارشش رو تهیه کنم.

💡 واقعا نیازه تا به Rust جدی فکر کنیم؟

چند وقته توی کامیونیتی توصیفات عجیب و غریبی توسط جَواگِره عزیز (جمع مکسر جوگیر) راجع به Rust می‌بینیم. گویی که «امروزه، عصر Rustنویسی است و مابقی کدها شایسته‌ی لعنت کائنات» (همینو در مورد چیزهای دیگه هم می‌بینیم، ولی باشه برای پست‌های بعدی 😁)

خیلی مهمه که بدونیم «چرا» لینوکس، ویندوز، اندروید و کلی پروژه مهم دیگه در حال بازنویسی برخی کدهای موجود و توسعه برخی کدهای جدیدشون با Rust هستن؟
مثلا توی کرنل ویندوز یک سال و نیمه که راست به صورت رسمی وجود داره (System32\win32kbase_rs.sys) یا لینوکس کرنل ۶.۱۳ که این هفته ریلیز شد علاوه بازهم بخش‌های جدیدتری رو با راست بازنویسی کرده (البته خیلی وقته برخی درایورهاش رو با راست نوشتن) و...

با اینکه فریم‌ورک وب و دسکتاپ و... برای راست می‌بینیم، حتی جایگزین برای الکترون و.. هم داره، باید قبل از افتادن توی حباب، ببینیم «چه مسئله» ای رو قراره برامون حل کنه!

علی‌ای‌حال؛ اگر خواستید بیشتر باهاش آشنا شید (برای یادگیری مفاهیم طراحی زبان، روش‌های مدیریت هم‌زمانی و حافظه و... مایکروسافت به عنوان یکی از اعضاء جدی و مهم بنیاد راست، مستندات خیلی خوبی ویژه‌ی توسعه‌دهندگان دات‌نت که قصد مهاجرت یا یادگیری Rust دارن، توسعه داده که می‌تونید به عنوان یک رفرنس عالی ازش استفاده کنید)

https://microsoft.github.io/rust-for-dotnet-devs/latest/

چند دقیقه ای طلایی از استاد سپندارند عزیز.

کلید موفقیت اُکالا در Distributed Transaction ها SAGA Orchestration است
👈🏻 چطور همچین پترنی رو توی دنیای میکروسرویس‌ها طراحی کنیم، اونم تو مقیاس بزرگی مثل اکالا؟ جواب این ویدیو است 🌟

💡 حالا مشکل کجاست؟
وقتی توی دنیای مونولیت هستیم، خیلی راحت با یک SQL Transaction همه‌چیز رو کنترل می‌کنیم.
اما توی دنیای میکروسرویس‌ها چی؟ 😟
پای چندین دیتابیس وسطه (از انواع مختلف).
دیگه خبری از اون روش‌های ساده نیست.
اینجاست که باید بریم سراغ Two-Phase Commit یا SAGA Pattern.

🎯 این ویدیو چی بهت یاد میده؟
1️⃣ عملیات Commit و Rollback با پروتکل Two-phase commit
2️⃣ عملیات Commit و Rollback با SAGA Choreography پترن
3️⃣ عملیات Commit و Rollback با SAGA Orchestration پترن

🎥 لینک‌ها:
📌 ویدیو: تماشا کنید
📌 پلی‌لیست دیزاین پترن‌ها: مشاهده کنید
📌 لینکدین من: بازکردن
⏰ مدت زمان ویدیو: 38 دقیقه

☕️ اگه ویدیو رو دوست داشتید میتونید از این لینک منو مهمون یک قهوه کنید ❤️

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

حسن از خوبای مهندسی نرم افزاره.

Learning With M pinned «سلام سلام
برای یک تحقیقات به نظر شما احتیاج دارم، ممنون میشم در این نظرسنجی شرکت کنید و همچنین تا جای ممکن با دوستانتون به اشتراک بزارید.
#چالش ۱۰۰۰ شرکت کننده! سوال: اگر ۱۰ واحد ارزش برای ماندگاری یا انتخاب یک شرکت داشته باشید، کدام یک انتخاب شماست؟»

درمورد DependencyInjection یکی از نکاتی که کمتر میبینم بهش توجه میشه اینه اگر شما یه شئ رو در زمان ریجستر کردن ایجاد کنید دیگه DI کنترلی روی ایجاد و حذفش نداره و این مسئولیت برنامه نویس هست که منابعی رو که توی اون کلاس استفاده میشه رو آزاد کنه.

نکته بد ماجرا اینجا شروع میشه که اگر از این روش برای AddScope استفاده بشه به ازای هر درخواست یه شئ ایجاد میشه و منابع آزاد نمیشه و بقیه ماجرا که خودتون بهتر میدونید!

بهترین روش اینه که بذارید خود DI کارشو انجام بده و درمورد خاص که راهی وجود نداره حتما اینترفیس IDisposable رو پیاده کنید.

شما ازین روش استفاده میکنید؟

استفاده از SWOT به راحتی به خطا میره. حالا در موردشون صحبت می کنم

📈تحلیل SWOT

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

اجزای تحلیل SWOT:

📌1. نقاط قوت (Strengths):

   • ویژگی‌ها یا منابعی که سازمان را در مقایسه با رقبا متمایز می‌کند.

   • مثال: برند قوی، تیم متخصص، فناوری پیشرفته.

📌2. نقاط ضعف (Weaknesses):

   • جنبه‌هایی که ممکن است مانع از موفقیت سازمان شود.

   • مثال: کمبود منابع مالی، ضعف در بازاریابی، مشکلات داخلی.

📌3. فرصت‌ها (Opportunities):

   • عوامل خارجی که می‌توانند به رشد و توسعه سازمان کمک کنند.

   • مثال: بازارهای جدید، تغییرات در قوانین و مقررات که به نفع کسب‌وکار باشد.

📌4. تهدیدها (Threats):

   • عوامل خارجی که ممکن است به موفقیت سازمان آسیب برسانند.

   • مثال: رقابت شدید، تغییرات اقتصادی نامساعد، تغییرات در سلیقه مشتریان.


#استراتژی
🔸آدرس سایت ناب《 لینک》


@strategicstudiesnab

برای 678 میخواستم عکس بگیرم، ولی یهو توی یک شب ترکید، الان از 789 براتون عکس گرفتم :)

خب به همین مناسبت و یه دلیل بی خودی برای شادیمون، تا آخر هفته اپیزود جدید پادکست رو منتشر می کنم که در مورد نحوه کار و جزئیات REDIS هست :)

بابا داشتن، یه شانسه.
امید وارم پدرهاتون سایشون بالاسرتون باشه.

دم بچه های علی بابا برای این ویدیو گرم.

امروز می‌خوام در مورد Exchange ها در RabbitMQ براتون بگم. Exchange ها مثل پستچی‌های پیام‌رسان عمل می‌کنن و تصمیم می‌گیرن پیام‌ها رو چطوری به صف‌ها (Queue) برسونن. بیاید ببینیم هر کدوم چیکار می‌کنن:

Direct Exchange 🎯
کارش چیه؟
پیام‌ها رو فقط به صف‌هایی می‌فرسته که کلید مسیریابی (Routing Key) دقیقاً همون چیزی باشه که تعیین کردیم.

کی استفاده کنیم؟
وقتی می‌خوایم پیام‌ها رو دقیقاً به یک صف خاص برسونیم. مثلاً پیام‌های "سفارش جدید" فقط به صف "پردازش سفارش" برن.

مثال:
Routing Key: order.created ➡️ Queue: order_queue

Fanout Exchange 📢
کارش چیه؟
پیام‌ها رو به همه صف‌های متصل شده می‌فرسته، بدون توجه به کلید مسیریابی.

کی استفاده کنیم؟
وقتی می‌خوایم یک پیام رو به چندین صف ارسال کنیم. مثلاً ارسال اطلاع‌رسانی به همه گروه های کاربران.

مثال:
پیام: "تخفیف ویژه!" ➡️ Queue: user_group1_queue, user_group2_queue, user_group3_queue

Topic Exchange 🌐
کارش چیه؟
پیام‌ها رو بر اساس الگوهای کلید مسیریابی ارسال می‌کنه. مثلاً می‌تونیم از wildcard (* و #) استفاده کنیم.

کی استفاده کنیم؟
وقتی می‌خوایم پیام‌ها رو بر اساس موضوع‌های مختلف دسته‌بندی کنیم. مثلاً خطاهای سیستم (error.*) یا لاگ‌های عمومی (log.#).

مثال:
Routing Key: error.database ➡️ Queue: error_queue

جمله روز:

Software development is a learning process; working code is a side effect.

- Alberto Brandolini