thisisnabi.dev [Farsi]

می دونید دیگه هفته آینده شاید کمی از لحاظ کاری سرمون خلوت باشه.

بیاید یه هکاتون ۸ ساعته برگزار کنیم که درش ایده مون رو تبدیل به محصول کنیم.

قاعدتا هم هزینه ثبت نام داره، و هم کل مبلغ جمع شده به ۲ تیم اول تعلق میگیره.

😎 من خودم اسپانسر زیرساخت میشم، یعنی شما دغدغه محیط اجرای برنامه تون رو نخواهید داشت، در کنارش از طرف خودم هم یک جایزه نقدی جداگانه به تیم اول تقدیم میکنم.

یک حدی هم برای ثبت نام میذاریم. به اون تعداد رسیدیم هکاتون رو برگزار میکنیم.

برای همین اگر خودتون شرکت نمی کنید، به دوستانتون بگید لطفا ❤️

خوشبختانه تجربه برگزاری هکاتون رو هم قبلا با کوئرا و همکاران سیستم داشتم برای همین خودمم ذوق دارم کنارش.

Update1:
یه ایده بر مبنای AI داشته باشید :)

Update2:
برنامه بوده که بخاطر نداشت پول هاست ناچار بوده ببنده سایتش رو. اینجوری شما برای بقای ایدتون اقلا یه مبلغ کوچکی جهت راه اندازی دارین.

3. Sharding

من این منابع برام جذاب بوده.

1. Designing Data-Intensive Applications
- Partitioning [Chapter]
- Replication [Chapter]

2. System Design Interview, Vol 1
- Design Consistent Hashing [Chapter]
- Design a Key-Value Store

3. NoSQL Distilled
- Distribution Models [Chapter]


Update 1:
همین عناوین ساده رو اگر با ما از روز اول استارت میزدید الان حدودا 350 صفحه کتاب خوب خونده بودید که درش بیش از 30 الگوریتم کار با دیتا رو هم یاد گرفته بودین.
رشد تدریجی هست، شما هم شروع کنید

Update 2:
لطفا تا مطالعه نکردین منابع رو پست رو لایک نکنید، که آمار دقیق از آدم ها داشته باشیم


@thisisnabi_dev

2. Data Partitioning

منابع پیشنهادی این چالش که برای من اینها جذاب بوده و هست.

A. Pro SQL Server Internals [book]
- Chapters 16 - required

B. MySql Docs
- site

Update 1:
منم دان ✌️

@thisisnabi_dev

1. Indexes

منابع پیشنهادی این چالش که برای من اینها جذاب بوده و هست.

A. Designing Data-Intensive Applications 2nd Edition [book]
- Chapter 4 - required

B. Database Internals [book]
- Chapters 1, 2 - required
- Chapter 3, 4 - optional

C. Pro SQL Server Internals [book]
- Chapters 1, 2, 4, 6 - required
- Chapters 3, 5 - optionals


قرار نیست زردآلو بیاد تو گلو باشه
رشد همیشه با کمی سختی، فشار و کش اومدن همراهه. هر وقت دیدی همه‌چی زیادی راحته، احتمالاً داری همون چیزهایی رو تکرار می‌کنی که بلدی.
گرم دم اونایی که با ما بودن و ادامه میدن ❤️

Update 1 :
من امروز که می خواستم کتاب اولی رو مجددا بخونم فهمیدم که ادیشن 2 هم اومده و این عنوان توی فصل چهارم هست برای همین آپدیت کردم تکست رو، در جریان باشید.
Update 2:
یکی از گلوگاه های بیزینس هایی مثل ما که همیشه انگار توی بلک فرایدی هستیم دیتابیس و محدودیت هاشه، برای همین خواستم با بزرگوار شروع کنید، پس اگر وقت داشتین حتما ۲ تا منبع اول رو بخونید :)

Update 3:
منم دان ✌️
@thisisnabi_dev

بچه ها بیاید با هم یک چالش بذاریم تا آخر سال بلکه یه نظمی در یادگیری پیدا کنیم.
من هر پنجشنبه ساعت 09:00 یک تاپیک رو معرفی میکنم با یکسری منبع، اگر منابع رو خوندید و موضوع رو یاد گرفتید پستش رو لایک کنید.

خواهشم اینه که اگر انجام ندادید لایک نکنید که آمارمون به هم نریزه.

@thisisnabi_dev

توی فرایند ساخت معمولا شما درگیر موارد زیر هستید
1. Communication
2. Planning
3. Modeling
4. Construction
5. Deployment

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

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

اینکه چطوری این فیچر ساجسشن رو دیزاین میکنن در نوع خودش جذابه :)

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

به همین دلیل بسیاری از معماران ترجیح می‌دن از اصطلاح Architectural Characteristics استفاده کنن.
زیرا این ویژگی‌ها نقش حیاتی در موفقیت سیستم دارند و نباید به‌عنوان نیازمندی‌های درجه دوم تلقی بشن.

یه بخشی از کتاب Fundamentals of software architecture

@thisisnabi_dev

بعضی پترن‌ها و ابزارها مثل 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://martinfowler.com/fragments/2026-06-02.html

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

یه جمله زیبا از کنت بک دیروز شنیدم که می گفت، قسمت زیبای ماجرا (بعد از اومدن AI) برای من اینه که دیگه به زبان برنامه نویسی اهمیت نمی دم.

البته میشه این‌طور تفسیر کرد که وقتی AI بتواند بین زبان‌ها ترجمه کند و کد تولید کند، ارزش دانستن جزئیات سینتکس یک زبان کاهش پیدا می‌کند. اما این با بی‌اهمیت شدن خوانایی برای انسان فرق داره.

به نظرم هنوز یه دلیل خیلی مهم وجود داره که زبان و کدهای human-readable اهمیت داشته باشن.

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

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

به نظرم حتی اگه AI بیشتر کدها رو بنویسه، هنوز هم باید خروجی نهایی برای آدم‌ها قابل فهم باشه؛ چون آخرش مسئولیت نگهداری و حل بحران‌ها با انسانه.

توی مبحث Resilience، برای من یکی از زیباترین استراتژی‌ها Fallback هست.

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

چون Plan B لزوماً برای استفاده روزمره نیست، بلکه برای اطمینان و ادامه کار در شرایط بحرانه، با هر قیمتی.

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

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

اوایل که BMW و بنز ماشین برقی تولید می‌کردن، می‌گفتم خداروشکر دیگه یه روزی از دست پراید و پژو خلاص می‌شیم و می‌تونیم یکی از این ماشین‌های برقی بگیریم، هزینه بنزین هم ندیم :)

الان یکی از بحران‌های آمریکا افزایش قیمت بنزینه و پراید سرپنجه با ۱۰ سال عمر هم تو ایران ۷۰۰ میلیون تومنه :))
هرچند این موضوع ربط مستقیمی به ماشین‌های برقی نداره، ولی خب واقعیت کف جامعه رو می‌خوام بگم.

به‌نظرم سر AI زیاد استرس نگیرید. با برنامه منظم سعی کنید نحوه استفاده ازش رو یاد بگیرید. در کنارش هم تمرکزتون روی Requirement Engineering، High-Level Design و فهم مسائل بنیادین باشه.
اولی باعث میشه نیاز اصلی رو بهتر تارگت کنید و دومی و سومی هم باعث میشه spec دقیقتر تولید کنید.

شما باید مسائل بنیادین رو بفهمید تا هم بتونید بهره بیشتری از AI ببرید و هم خروجی‌هاش رو درست ارزیابی کنید.

نرم‌افزار فقط چند خط کد نیست که به AI بگید براتون تولید کنه؛ یک اکوسیستمه که باید بلد باشید شکلش بدید.

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

این کتاب fundamentals of software architecture هم هست! اون رو سعی میکنم از رو کتاب ویس هاشو رکورد کنم براتون بذارم. خیلی وقته می خواستم و وقت نمیشد، از این هفته براتون حتما ویس هاش رو میذارم.