thisisnabi.dev [Farsi]

/learn

احیانا اگر claude دارین، این عناوینی که بصورت هفتگی بهتون میدم رو با این اسکیل بذارید، تر و تمیز، قدم به قدم موضوع رو یادتون میده.

7. Multileader replication —- 1. Designing Data Intensive Applications - Replication [6] @thisisnabi_dev

من واقعا دغدغه که بتونم این تضمین رو بدم که وقتی یک نفر به امید گرفتن سفارش کرکره مغازه اش رو میده بالا سفارش رو سالم برسونیم دستش. سخته اما شدنیه. @thisisnabi_10x_developer

کتاب خوب بخونید.

قرار نیست که در همه جای برنامه از AI استفاده کنیم، در جاهایی که نیاز به قطعیت هست همون کد های کثیف سابق باید بمونه :) اینجا توضیحات بیشتر دادم. @thisisnabi_dev

اگر قرار باشه دوباره درگیر ساختار های دست و پاگیر در فرایند توسعه نرم افزار بشیم باز رسیدن به خروجی زمانبر خواهد بود. و این دوباره تمرکز ما رو از نیت اصلی دور میکنه. چند روز پیش با یک پروداکت منیجر بصورت تمرینی روی یک PRD کار می کردم و با هم pair شده بودیم، یک داشبورد کامل رو با درنظر گرفتن اکثر جزئیات بیزینسی در 4.5 ساعت کار آماده کردیم. فرایند ها بنظرم کمی به این سمت میره که بیزینس دیگه از شما نمیپزیره یک کار رو چند ماه طول بدین، باید خیلی سریع به فکر ارائه خروجی باشید. برای همین بشخصه تمرکزم روی تغییر مدل کاری تیم و چیدن ساختاری برای رسیدن سریعتر به خروجی هست. حتی یک موضوعی که این روزها فکرم رو درگیر کرده اینه که دیگه اینقدر راحت مثل قبل نیرو در اختیارمون قرار نمیدن، دیدگاه رفته به سمتی که چرا یه بیزینس میلیارد دلاری توی سیلیکون ولی با 10 نفر پیش میره، شما هم برید به اون سمت، کارهای دست و پاگیرتون رو با AI پیش ببرید. این تغییر نشونه بیکارشدن ما نیست ولی بیزینس چی براش کمتر هزینه داشته باشه میره به اون سمت، تا بوده همین بوده. شما سعی کنید مسبب این کاهش هزینه باشید.

وقتی یه agent متونه کد بنویسه، قاعدتا می تونه API هم کال کنه. چرا من فکر می کنم MCP زیاد جواب نیست :/

6. Single Leader Replication —- 1. Designing Data Intensive Applications - Replication [6] @thisisnabi_dev

2 اسپرینت کار بود خدایی :)

من هر موقع موضوعی برام پیچیدس سعی می کنم یه گروه بندی از موضوعات بسازم و بعد کم کم هر گروه رو یاد بگیرم. این تصویر هم برای خودم کمک کننده بوده.

این موضوع جذابی هست، لینک مقاله اصلی هم درش گذاشتم. https://www.linkedin.com/posts/thisisnabi_ai-softwareengineering-aiengineering-share-7483907757029486592-6Lyh/?utm_source=share&utm_medium=member_desktop&rcm=ACoAABdqDr0BJIj7gy7oW3facT7ro7bITsW3Ay0

من توی این تعطیلات درگیر ریفکتور یه سیستم نسبتا بزرگ بودم که حدودا 2 روز زمان من رو گرفت. در تمام این 2 روزی که درگیر بودم یک بار هم به محدودیت مصرف توکن نخوردم. خیلی با حوصله برای دوست عزیزمون توضیح می دادم و اون هم زحمت انجام کار رو می کشید، اینکه دقیقا بدونید چی می خواید خیلی روی مصرف توکن (هزینه) تاثیر گذار هست. اینطوری نباشید که دیگه AI هست، چیزی که من بلدم ارزشی دیگه نخواهد داشت.

کتاب خوب بخونیم. این کتابه کمی گم هست و کم دیدم در موردش صحبت کنن، ولی واقعا کتاب خوبی هست. دیشب توی میت های 10x developer معرفیش کردم، گفتم اینجا هم برای شما هم بذارمش شاید کسی علاقه داشت بخوندش. کلا این سری کتاب های pragmatic خیلی ارزش خوندن دارن و نگاه آدم رو نسبت به موضوعی که قرار هست مطرح کنن، تغییر می دن. @thisisnabi_dev

5. Stream Processing من این منابع برام جذاب بوده، کتاب دومه رو وقت کردین پلن کنید که توی 3 ماه کامل بخونید :) 1. Designing Data-Intensive Applications E2 - Stream Processing [12] 2. Streaming Systems @thisisnabi_dev

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

بعد از چند سانحه معروف، از جمله حادثه پرواز Korean Air Flight 801 crash، مشخص شد که یکی از مشکلات، فرهنگ سازمانی بسیار سلسله‌مراتبی بود؛ کمک‌خلبان‌ها گاهی به جای اینکه مستقیم بگویند «اشتباه می‌کنید»، با تعارف یا اشاره غیرمستقیم حرف می‌زدند. این موضوع باعث شد صنعت هوانوردی کره آموزش‌های گسترده‌ای روی ارتباط مستقیم اجرا کند تا هر عضو خدمه، بدون ملاحظه جایگاه، در شرایط بحرانی واضح و صریح حرف بزند.

سال گذشته 2025 شروع کردیم به دوره 10x دولوپر که رسالت اصلیش این هست که میگه شما باید برای agent دقیقا مشخص کنید چی می خواید که این از یک شناخت و آگاهی میاد، شما باید موضوعات متفاوتی رو بدونید تا قدرت تصمیم و انتخاب داشته باشید وگرنه خروجی agent همیشه به نفع شما نیست. در اولین ساختمونی که ساختم پیمانکار تاسیساتمون یه حرف قشنگی بهم زد که اگر می خوای سوخت زیاد ندی باید خودت هم قوانین نظام مهندسی رو بلد باشی تا به پیمانکارهات بگی دقیقا چی می خوای که هزینه زیاد رو دستت نذارن، برای نمونه برق کار ما در یک طبقه که گفتم چی درسته خودت همون رو انجام بده 18 تا هالوژن اضافه مصرف کرده بود، این جدای از سیم و کثافتی بود که زیر کار بود :) . در vibe coding هم همینه، شما اگر قواعد درست رو مشخص نکنی هزینه تمام شده کارت بالا میره بعضیش جلوی چشمه مثل توکنی که مصرف میشه و بعضیش هم زیر کاره و بعدا صداش در میاد. @thisisnabi_10x_developer

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