thisisnabi.dev [Farsi]

توی فرایند ساخت معمولا شما درگیر موارد زیر هستیم 1. Communication 2. Planning 3. Modeling 4. Construction 5. Deployment در صنعت های خیلی قدیمی تر مثل ساختمان سازی، یک مهندس بیشتر درگیر Communication، Planning و Modeling هست. یعنی در واقع کمتر میبینید مهندسی رو که لباسش سر کار کثیف بشه و معمولا بنا ها و کارگر ها زحمت Construction و Deployment رو بر عهده دارن. توی صنعت نرم افزار که خب خیلی نوپاتر هست نسبت به ساخت و ساز کسی رو نداشتیم که 2 مورد آخر رو برامون انجام بده و خودمون مجبور بودیم کد بنویسیم. حالا تصور کنید AI قرار هست زحمت 2 مورد آخر رو برامون بکشه. این نگاه رو حسین هلالی عزیز بهم داد، بنظرم خیلی درست و جای تامل داره. برای همین این روزها من بیشتر درگیر 3 مورد بالا هستم.

معماری باید در راستای حل business problems باشه. وگرنه میشه اداس :)

جلسه 9 هم آپلود شد.

اینکه چطوری این فیچر ساجسشن رو دیزاین میکنن در نوع خودش جذابه. توی اون میت های سیستم دیزاین یادمه رای گیری ۲۰۲۴ آمریکا رو شبیه سازی کرده بودیم، ۵۷ میلیون رای در یک روز که باید پردازش بشه و نهایتا برنده مشخص بشه. وقت کردین نگاه کنید، در نوع خودش جذاب بود.

احیانا اگر دارین این کتاب رو ممنون میشم به ما هم بدید.

یکی از زیباترین نکاتی که در مورد موضوعاتی مانند Performance، Security، Scalability، Legality و سایر ویژگی‌های معماری مطرح میشه این که نباید آن‌ها را Non-Functional Requirements بنامیم. دلیلش اینه که پیشوند Non به‌صورت ناخودآگاه بار معنایی منفی ایجاد می‌کنه و اهمیت این نیازمندی‌ها رو کمتر از نیازمندی‌های عملکردی نشون می‌ده. در چنین شرایطی این سؤال مطرح می‌شه که "چگونه می‌توان یک تیم را متقاعد کرد زمان و انرژی کافی برای چیزی صرف کند که از همان ابتدا غیرعملکردی نامیده شده است؟" به همین دلیل بسیاری از معماران ترجیح می‌دن از اصطلاح Architectural Characteristics استفاده کنن. زیرا این ویژگی‌ها نقش حیاتی در موفقیت سیستم دارند و نباید به‌عنوان نیازمندی‌های درجه دوم تلقی بشن.

بعضی پترن‌ها و ابزارها مثل Rate Limit یا Circuit Breaker از اون چیزهایی نیستند که بتونید از روز اول براشون عددهای دقیق تعیین کرد. بهترین کار این هستش که از ابتدا لاگ، متریک یا هر داده‌ای که لازم دارید رو ثبت کنید تا وقتی یک اینسیدنت رخ داد، بر اساس اتفاقات واقعی تنظیمات رو بازبینی و برای دفعات بعد بهتر کانفیگ کنید. در واقع این مدل کارها همیشه باید بر اساس محیط عملیاتی تنظیم بشن. @thisisnabi_dev

دیشب توی این میت هامون یکی از بچه ها این لینک رو باهامون به اشتراک گذاشت، امروز صبح نگاه کردم و منبع باکیفیتی هست بنظرم. بد نیست یه نگاهی بهش بندازید و یه 2 ساعتی روش وقت بذارین. یا اقلا هفته آینده 2 سه باری از اول این رو نگاه کنید بچه ها. Spec-Driven Development with Coding Agents - DeepLearning.AI

همچنان که می دونید معماری نرم افزار فقط ساختار برنامه (structure) نیست. ابعاد مختلف دیگری هم مثل architecture characteristic, architecture decision, design principles داره که درمدل های توسعه نرم افزار Agent محور هم نباید نادیده گرفته بشه. دلیلم برای این حرف اینه که وقتی شما به یک Agent در 2 ترد مختلف میگید مثلا یه بستک فروش برام بساز، خروجی ها می تونند متفاوت باشد، برای همین واسه گرفتن یک خروجی درست تر خود agent هم نیاز به آگاهی بیشتری از مشخصه های دامنه، تصمیمات معماری و اصول مشخص ما داره. احتمالا در کتاب های آینده این مدل توسعه نرم افزار رو بیشتر برامون شفاف میکنن اما بنظرم باید اینها دیده بشه. 1. چطور کار می کنیم، بیشتر دستورالعمل های agent هستش 1. چی میسازیم (feature-scope) 3. چطور بسازیم (مشخصه ها + تصمیمات + اصول )

نصف دولوپر های ایران با این تابلوی "حاجی بک انده" عکس گرفتن. کاش یه تابلو می بود با عنوان "حاجی از دواپسه" قطعا میرفتم باهاش عکس میگیرفتم :/

این مقاله اخر این قسمتش برام جذاب بود: وجود آشفتگی و بدهی فنی در یک کدبیس همیشه باعث اصطکاک در توسعه نرم‌افزار شده است، اما وقتی مدل‌های زبانی از همان کد به‌عنوان زمینه کارهای بعدی استفاده می‌کنند، پیامدهای این آشفتگی چند برابر می‌شود. برای همین بنظرم باز نیاز هست یه تمیز کاری هایی انجام داد و بعد کد رو به AI سپرد. یا حداقل در سطح کد یک refactoring action plan آماده کرد که دوست عزیزمون به ... نده. https://www.linkedin.com/safety/go/?url=https%3A%2F%2Fmartinfowler%2Ecom%2Ffragments%2F2026-06-02%2Ehtml&urlhash=_01O&mt=nEubpo7x7vCzWcGAlykaqeulNO27-4guIs6NT6g3gUpC5VcMQxqEFAiZ5OPYwUHdAIGqb79jbnzE4luIFWr3aST4akF5s14v_w6qATKlivwjWjVp6kn_DI4GEg&isSdui=true

این رو خوندید دیگه درسته؟ تا کتاب دیگه بهتون معرفی کنم 😊

دیروز از کنت بک شنیدم که می‌گفت بعد از اومدن AI دیگه خیلی براش زبان برنامه‌نویسی مهم نیست. البته میشه این‌طور تفسیر کرد که وقتی AI بتواند بین زبان‌ها ترجمه کند و کد تولید کند، ارزش دانستن جزئیات سینتکس یک زبان کاهش پیدا می‌کند. اما این با بی‌اهمیت شدن خوانایی برای انسان فرق داره. به نظرم هنوز یه دلیل خیلی مهم وجود داره که زبان و کدهای human-readable اهمیت داشته باشن. فرض کنید روی یه سیستم واقعی که هر لحظه هزاران تراکنش داره، یه باگ بحرانی پیدا شده و باید سریع فیکسش کنید. اگه اون لحظه Agent در دسترس نباشه چی؟ اون موقع تیم باید خودش بتونه کد رو بخونه، بفهمه و تغییرش بده. اگر کدی داشته باشیم که فقط AI راحت می‌فهمدش و برای آدم‌ها سخت و مبهمه، توی شرایط بحرانی دردسر بزرگی درست می‌کنه. برای پروژه‌های شخصی، دموها یا فضای دانشگاهی شاید خیلی مهم نباشه. ولی توی بیزنس‌های واقعی که قطعی، تأخیر یا از دست رفتن درآمد هزینه داره، نمی‌شه فهم سیستم رو کامل به حضور AI گره زد. به نظرم حتی اگه AI بیشتر کدها رو بنویسه، هنوز هم باید خروجی نهایی برای آدم‌ها قابل فهم باشه؛ چون آخرش مسئولیت نگهداری و حل بحران‌ها با انسانه.

سلام. عزیزانی که پیام دادن امروز تا اخر وقت حتما دسترسی هاتون رو میدیم.

عنوان سرویس هاشم اینا بودن 1. Search as a service [5:13:08] 2. Media as a service [4:15:22] 3. Shortener as a service [4:14:05] 4. Reminder as a service [4:21:30] 5. Notify as a service [4:48:05] 6. Location as a service [4:48:42] 7. Text Storage as a service [4:43:06] 8. Chat as a service [6:39:25] 9. Reaction as a service [6:09:08] 10. Jobs as a service [4:52:24] 11. Feedback as a service [3:17:30] 12. Leaderboard as a service [3:47:01] 13. Basket as a service [3:58:03] 14. Identity Provider as a service [11:34:59] 15. Election Board as a service [4:32:42] 16. Map as a service [2:44:33] 17. Profile as a service [5:59:50] 18. Reservation as a service [2:34:49] 19. IPG as a service [2:16:57] 20. Payment as a service [2:05:40] 21. Otp Authorizer as a service [2:31:02] 22. Wallet as a service [3:26:21] 23. Affilate as a service [1:01:31] 24. Subscription as a service [47:36] 25. Scoring as a service [1:21:40] حتی اگر دوست داشتین می تونید توی کانالی چیزی دارین ویدیو هاش رو آپلود کنید که اگر به درد کسی خورد استفاده کنه. خلاصه همین ها رو هم پنجشنبه ها توی ویدیو میت های 10x developer بهتون گفتم و خواهم گفت

سلام و وقت بخیر کلا من عجولم، نتونستم تا فردا تحمل کنم :) برای دریافت رایگان ویدیو های سیستم دیزاین 2 سال پیش به اکانت @thisisnabi_admin پیام بدین. توی این ویدیو ها فقط مباحث تکنیکال رو صحبت نکردیم، دغدغه های شرکت های داخلی و مدل های کاریشون رو هم یه کلنگی زدیم. فقط یه آدرس جیمیل بدین و بعد از دسترسی دانلود بفرمایید.

توی مبحث Resilience، برای من یکی از زیباترین استراتژی‌ها Fallback هست. Fallback فقط یه الگوی کد نیست، یه قانون بقا بیزینسی هستش. معمولاً بعد از هر محدودیت و مشکلی، سیستم‌های هوشمند راه جایگزین می‌سازن. ایده کانال یا خط لوله امارات هم دقیقاً در همین راستاست. توافق بشه یا نشه، مسیر فال‌بک ساخته می‌شه. چون Plan B لزوماً برای استفاده روزمره نیست، بلکه برای اطمینان و ادامه کار در شرایط بحرانه. با هر قیمتی.

تیم قوی فقط برای تقسیم کار نیست؛ تیم قوی به آدم جرئت می‌ده تا به انجام کارهای بزرگ فکر کنه.

جلسه 7 آپلود شد.

:)