COMPΞZ 🧬
وقتی بعضیها یه برنامه رو دو روزه با AI میسازن و فکر میکنن حله یا در بهترین حالت فکر میکنن بخش احراز هویت یعنی یه جدول user و یا چهارتا فیلد و فوقش یه API و JWT... ما از روی حماقت نه از روی اهمیت دادن به معماری، خودِ احراز هویت رو یه پروژه میبینیم. 😁 …
چیزی که ازش لذت میبرم توی این پروژه اینه که دارم سعی میکنم ساختار و معماری رو کاملاً بهروز با استاندارد ۲۶ زبان پیش بره که بعداً مجبور نشیم کالبدشکافی کنیم.
مواردی مثل
بعد از تأییدیه اولیه و آزمایشهای سطح بالا هدفم اینه سند مربوط به گواهی ISO رو بعد از انتشار از سازمان استانداردسازی بخرم.
این چیز عجیب و غریبی خواهد بود و ممکنه حین توسعه مدام ویژگیهای جدید از زبان رو ارتقاء بدم؛ اما یک بار برای همیشه از شر بازنویسیهای احراز هویت در هر پروژه خلاص خواهیم شد. 😎😌
برنامهنویسی با استانداردهای جدید ++C واقعاً لذتبخشه! همش میگی یاد بگیرم هرچی کد قدیمی دارم رو ارتقاء بدم به روشهای جدیدتر.
مواردی مثل
std::text_encoding یا std::monostate و embed# از استاندارد که به تازگی روی کامپایلرهای جدید در دسترس قرار گرفته فوقالعاده هستن.بعد از تأییدیه اولیه و آزمایشهای سطح بالا هدفم اینه سند مربوط به گواهی ISO رو بعد از انتشار از سازمان استانداردسازی بخرم.
این چیز عجیب و غریبی خواهد بود و ممکنه حین توسعه مدام ویژگیهای جدید از زبان رو ارتقاء بدم؛ اما یک بار برای همیشه از شر بازنویسیهای احراز هویت در هر پروژه خلاص خواهیم شد. 😎😌
برنامهنویسی با استانداردهای جدید ++C واقعاً لذتبخشه! همش میگی یاد بگیرم هرچی کد قدیمی دارم رو ارتقاء بدم به روشهای جدیدتر.
COMPΞZ 🧬
برنامهنویسی با استانداردهای جدید ++C واقعاً لذتبخشه! همش میگی یاد بگیرم هرچی کد قدیمی دارم رو ارتقاء بدم به روشهای جدیدتر.
چطور بفهمیم یک فناوری واقعاً در پروژه ما قابل استفاده است؟
یکی از چیزهایی که از زمان توسعه خیلی جدیتر بهش دقت میکنم، چیزی است به نام:
Technology Capability Baseline
یعنی یک سند ساده داخل پروژه که مشخص میکند که:
- چه فناوریهایی واقعاً کار میکنند؟
- کدامها در محیط فعلی آزمایشی هستند؟
- کدامها فقط روی کاغذ وجود دارند؟
- چرا یک قابلیت استفاده شده یا عمداً کنار گذاشته شده؟
چرا مهم است؟
چون بعد از چند ماه یا چند سال، نه خودتان و نه حتی AI همیشه دلیل تصمیمهای قبلی را نمیدانید. ممکن است یک ویژگی جدید را فقط چون «وجود دارد» وارد پروژه کنید، بدون اینکه بدانید در معماری واقعی شما چه مشکلی ایجاد میکند.
مثلاً در پروژه C++26 خودم:
ویژگی جدید Reflection توسط کامپایلر پشتیبانی میشود و خارج از پروژه هم بدون مشکل اجرا میشود؛ اما وقتی وارد ساختار واقعی پروژه با Module Partition میشود، مشکل ایجاد میکند.
پس وضعیت واقعی آن Available but Blocked است؛ نه اینکه بگوییم «پشتیبانی نمیشود»؛ چون این اشتباه است.
یا مثلاً
این تفاوت خیلی مهم است:
پشتیبانی شده (Supported) روی کاغذ برابر نیست با آماده (Ready) برای پروژه!
این نوع مستندسازی کمک میکند هم مهندسها و هم عاملهای هوش مصنوعی هنگام تحلیل و توسعه، تصمیمهای واقعی پروژه را در نظر بگیرند.
مهندسی نرمافزار فقط نوشتن کد نیست؛ ثبت دلیل تصمیمها، شناخت محدودیتها و فهمیدن مرزهای واقعی تکنولوژی هم بخشی از ساخت یک سیستم حرفهای است.
وگرنه چیزی که میسازید بعد از مدتی تبدیل به مجموعهای از تصمیمهای فراموششده و بدهی فنی خواهد شد.
هر از گاهی سعی میکنم یه سری نکتههارو بگم که چطور AI رو وادار کنید دقیقاً مبتنی بر مهندسی برای شما کار کنه.
پست بعدی فایل دستور یا پرامپتی که میتونید دقیقاً همچین چیزی رو برای پروژتون بسازید رو میفرستم که همچین ساختاری خواهد داشت:
یکی از چیزهایی که از زمان توسعه خیلی جدیتر بهش دقت میکنم، چیزی است به نام:
Technology Capability Baseline
یعنی یک سند ساده داخل پروژه که مشخص میکند که:
- چه فناوریهایی واقعاً کار میکنند؟
- کدامها در محیط فعلی آزمایشی هستند؟
- کدامها فقط روی کاغذ وجود دارند؟
- چرا یک قابلیت استفاده شده یا عمداً کنار گذاشته شده؟
چرا مهم است؟
چون بعد از چند ماه یا چند سال، نه خودتان و نه حتی AI همیشه دلیل تصمیمهای قبلی را نمیدانید. ممکن است یک ویژگی جدید را فقط چون «وجود دارد» وارد پروژه کنید، بدون اینکه بدانید در معماری واقعی شما چه مشکلی ایجاد میکند.
مثلاً در پروژه C++26 خودم:
ویژگی جدید Reflection توسط کامپایلر پشتیبانی میشود و خارج از پروژه هم بدون مشکل اجرا میشود؛ اما وقتی وارد ساختار واقعی پروژه با Module Partition میشود، مشکل ایجاد میکند.
پس وضعیت واقعی آن Available but Blocked است؛ نه اینکه بگوییم «پشتیبانی نمیشود»؛ چون این اشتباه است.
یا مثلاً
std::simd صرفاً چون یک قابلیت جدید C++26 است، نباید فرض کنیم آماده استفاده است. بررسی مشخص کرد که در محیط فعلی من روی معماری aarch64 محدودیتهایی وجود دارد و قابل استفاده نیست.این تفاوت خیلی مهم است:
پشتیبانی شده (Supported) روی کاغذ برابر نیست با آماده (Ready) برای پروژه!
این نوع مستندسازی کمک میکند هم مهندسها و هم عاملهای هوش مصنوعی هنگام تحلیل و توسعه، تصمیمهای واقعی پروژه را در نظر بگیرند.
مهندسی نرمافزار فقط نوشتن کد نیست؛ ثبت دلیل تصمیمها، شناخت محدودیتها و فهمیدن مرزهای واقعی تکنولوژی هم بخشی از ساخت یک سیستم حرفهای است.
وگرنه چیزی که میسازید بعد از مدتی تبدیل به مجموعهای از تصمیمهای فراموششده و بدهی فنی خواهد شد.
هر از گاهی سعی میکنم یه سری نکتههارو بگم که چطور AI رو وادار کنید دقیقاً مبتنی بر مهندسی برای شما کار کنه.
پست بعدی فایل دستور یا پرامپتی که میتونید دقیقاً همچین چیزی رو برای پروژتون بسازید رو میفرستم که همچین ساختاری خواهد داشت:
docs/technology-capability-baseline.md
COMPΞZ 🧬
چطور بفهمیم یک فناوری واقعاً در پروژه ما قابل استفاده است؟ یکی از چیزهایی که از زمان توسعه خیلی جدیتر بهش دقت میکنم، چیزی است به نام: Technology Capability Baseline یعنی یک سند ساده داخل پروژه که مشخص میکند که: - چه فناوریهایی واقعاً کار میکنند؟ …
technology-capability-baseline.md
11.5 KB
این پرامپت اگه بخوام براش ارزشگذاری کنم؛ بدون تعارف هزاران دلار! 😉 چون چیزی از خروجی یک تفکر مهندسیه.
خودم از همچین ساختاری استفاده میکنم تا جزئیات از وضعیت فناوریهای مربوط به یک پروژه هم برای خودم هم برای عامل هوش مصنوعی صریحاً تعریف و مشخص باشه.
این موارد بسیار مهمن؛ درسته که عامل هوش مصنوعی سرعت توسعه رو میبره بالا اما مهمتر از همه کنترلش هست.
هرچند میدونم چون مفت میدمش ازش استفاده نخواهید کرد؛ صرفاً خواستم بدونید کار کردن با هوش مصنوعی اونی نیست که توی اینستاگرام یا شبکههای اجتماعی براتون میگن، باید مهندسی کنی اونم عمیق بر مبنای تجربه و علوم کامپیوتر و نرمافزار. 👊🏼
خودم از همچین ساختاری استفاده میکنم تا جزئیات از وضعیت فناوریهای مربوط به یک پروژه هم برای خودم هم برای عامل هوش مصنوعی صریحاً تعریف و مشخص باشه.
این موارد بسیار مهمن؛ درسته که عامل هوش مصنوعی سرعت توسعه رو میبره بالا اما مهمتر از همه کنترلش هست.
هرچند میدونم چون مفت میدمش ازش استفاده نخواهید کرد؛ صرفاً خواستم بدونید کار کردن با هوش مصنوعی اونی نیست که توی اینستاگرام یا شبکههای اجتماعی براتون میگن، باید مهندسی کنی اونم عمیق بر مبنای تجربه و علوم کامپیوتر و نرمافزار. 👊🏼
COMPΞZ 🧬
technology-capability-baseline.md
این رو میبینی، API GUIDE یا اون AUDIT رو؟ اینا مسخره بازی نیستن همشون پشتش منطقی خوابیده که هوش مصنوعی رو مسیردهی و رام میکنه.
اون یک پرامپت هزاران خطیه که حاصل سالها تجربست و ساختار رابطهای برنامهنویسی پروژه رو صریحاً مستندسازی میکنه و هربار ممیزی که باید انجام بشه رو سپری میکنه تا هر کدی که نوشته میشه از روند ممیزی کیفی بگذره و تا وقتی که تأیید نشه امکان نداره خروجی پروژه رو برای شما منتشر کنه.
این چیزهایی هستن که خیلیها حتی روحشون هم خبر نداره ازشون... و شرکتهای بزرگ مثل ادوبی، مثل مایکروسافت، گوگل، اپل و ... یا آمازون چرا یهو هزاران کارمند رو اخراج میکنن؟
قبلاً هم گفتم همشون این مدل ساختار توی پروژههاشون به کمک مهندسین ارشد میسازن که یه ارتش توسعه تربیت کنن.
حالا شما اگه نشستی داری هنوز دستی کد مینویسی و فکر میکنی برنامهنویسی سنتی هنوز هم خواهان داره... یکم باید تجدید نظر کنی چون فکرشو بکن من بیام همچین قراردادی رو برای شرکت شما بنویسم طوری که انگار ده نفر عین خودم رو اونجا استخدام میکنن! چی میشه؟ مزیت شما در اون سازمان چه خواهد بود؟
اینطوریه که حذف میشید.
اون یک پرامپت هزاران خطیه که حاصل سالها تجربست و ساختار رابطهای برنامهنویسی پروژه رو صریحاً مستندسازی میکنه و هربار ممیزی که باید انجام بشه رو سپری میکنه تا هر کدی که نوشته میشه از روند ممیزی کیفی بگذره و تا وقتی که تأیید نشه امکان نداره خروجی پروژه رو برای شما منتشر کنه.
این چیزهایی هستن که خیلیها حتی روحشون هم خبر نداره ازشون... و شرکتهای بزرگ مثل ادوبی، مثل مایکروسافت، گوگل، اپل و ... یا آمازون چرا یهو هزاران کارمند رو اخراج میکنن؟
قبلاً هم گفتم همشون این مدل ساختار توی پروژههاشون به کمک مهندسین ارشد میسازن که یه ارتش توسعه تربیت کنن.
حالا شما اگه نشستی داری هنوز دستی کد مینویسی و فکر میکنی برنامهنویسی سنتی هنوز هم خواهان داره... یکم باید تجدید نظر کنی چون فکرشو بکن من بیام همچین قراردادی رو برای شرکت شما بنویسم طوری که انگار ده نفر عین خودم رو اونجا استخدام میکنن! چی میشه؟ مزیت شما در اون سازمان چه خواهد بود؟
اینطوریه که حذف میشید.
COMPΞZ 🧬
این رو میبینی، API GUIDE یا اون AUDIT رو؟ اینا مسخره بازی نیستن همشون پشتش منطقی خوابیده که هوش مصنوعی رو مسیردهی و رام میکنه. اون یک پرامپت هزاران خطیه که حاصل سالها تجربست و ساختار رابطهای برنامهنویسی پروژه رو صریحاً مستندسازی میکنه و هربار ممیزی…
حالا تصور کن یک AGENT مهندسی واقعی در سطح یک مهندس ارشد بسازی؛ یعنی یه کپی (کلون از خودم) نه یک چتبات که فقط جواب بده یا مثلاً پروژه رو بررسی و توسعه بده!
تمام چیزهایی که یک مهندس ارشد باید بدونه رو بهش میدی:
معماری پروژه، استانداردها، کدها، تستها، مستندات، تصمیمهای فنی، محدودیتهای زیرساخت، تجربههای قبلی و حتی اینکه چرا یک تصمیم گرفته شده.
نتیجه؟
یک مهندس دیجیتال که خسته نمیشه، چیزی یادش نمیره و هر لحظه میتونه کل سیستم رو بررسی کنه اما تحت نظر متخصص اصلی کار میکنه و هیچ چیزی رو بدون نظر اون تأیید یا پیش نمیبره.
فکر کن یک مدیر میاد میگه:
«من یک CRM برای سازمانم میخوام.»
و مهندس ارشد به روی چشم!
نه ماهها جلسه، نه جنگ بین تیمها، نه اینکه یکی بگه من Front کارم، اون یکی بگه من Backend کارم، بعد آخرش نصف پروژه به خاطر هماهنگ نشدن آدمها بخوابه.
مدل قدیمی توسعه نرمافزار کمکم تغییر میکنه.
چون خیلی وقتها هزینه واقعی پروژه، نوشتن کد نیست؛ هزینه واقعی، هماهنگی، انتقال دانش، اشتباهات انسانی، فراموشی تصمیمها و مدیریت پیچیدگیهاست.
آینده این شکلیه:
یک مهندس ارشد انسانی + چندین Agent تخصصی هوشمند
یکی معماری رو بررسی میکنه، یکی امنیت رو، یکی تست مینویسه، یکی کد Review میکنه، یکی مستندات رو زنده نگه میداره.
همه با یک حافظه مشترک و شناخت کامل از پروژه.
پروژهای که امروز شاید ۱ میلیون دلار هزینه داشته باشه، میتونه فردا با بخش کوچکتری از هزینه و حتی کیفیت بالاتر ساخته بشه.
نه به این معنی که برنامهنویسها حذف میشن؛ ولی دنیا از شر برنامهنویسهایی که دبه میکنن یا چه بدونم فقط نوک دماغ خودشون رو میبینن خلاص میشه! چون ارزش واقعی از صرفاً کدنویسی کردن به سمت مهندسی، طراحی سیستم و حل مسئله منتقل میشه و شما باید در سطح بسیار بالاتری کار کنی.
نمیخوام دلسرد کنم بعضیها رو اما به نظر من جونیور یا سطوحی که تجربیات معماری و مهندسی ندارن دیگه عملاً در بازار حرفی برای گفتن نخواهند داشت.
شرکتها فقط دنبال این نیستن که چند نفر برنامهنویس استخدام کنن؛ دنبال کسی هستن که بتونه یک سیستم پیچیده رو هدایت کنه و از AI مثل یک تیم کامل مهندسی استفاده کنه و ارزش افزوده رو مدام ارتقاع بده. ارزشافرینی کنه و به عنوان یک مهرهٔ کلیدی حضور داشته باشه.
این چیزیه که همین الآن هم اتفاق افتاده اما به شدت خام هست و هرکسی که بتونه سریع به چنین سطحی برسه سهم خوبی از نیازمندیهای بازار رو به دست خواهد گرفت. 😉
این حرفارو میتونستم نزنم خیلیها هم تو خواب و غفلت بمونن ولی واقعیت اینه جانم، باید بری سمت یاد گرفتن معماری و اصول ساخت و توسعه. چون دیگه چطور بسازم مهم نیست، چرا و با چی بسازم مهمه.
تمام چیزهایی که یک مهندس ارشد باید بدونه رو بهش میدی:
معماری پروژه، استانداردها، کدها، تستها، مستندات، تصمیمهای فنی، محدودیتهای زیرساخت، تجربههای قبلی و حتی اینکه چرا یک تصمیم گرفته شده.
نتیجه؟
یک مهندس دیجیتال که خسته نمیشه، چیزی یادش نمیره و هر لحظه میتونه کل سیستم رو بررسی کنه اما تحت نظر متخصص اصلی کار میکنه و هیچ چیزی رو بدون نظر اون تأیید یا پیش نمیبره.
فکر کن یک مدیر میاد میگه:
«من یک CRM برای سازمانم میخوام.»
و مهندس ارشد به روی چشم!
نه ماهها جلسه، نه جنگ بین تیمها، نه اینکه یکی بگه من Front کارم، اون یکی بگه من Backend کارم، بعد آخرش نصف پروژه به خاطر هماهنگ نشدن آدمها بخوابه.
مدل قدیمی توسعه نرمافزار کمکم تغییر میکنه.
چون خیلی وقتها هزینه واقعی پروژه، نوشتن کد نیست؛ هزینه واقعی، هماهنگی، انتقال دانش، اشتباهات انسانی، فراموشی تصمیمها و مدیریت پیچیدگیهاست.
آینده این شکلیه:
یک مهندس ارشد انسانی + چندین Agent تخصصی هوشمند
یکی معماری رو بررسی میکنه، یکی امنیت رو، یکی تست مینویسه، یکی کد Review میکنه، یکی مستندات رو زنده نگه میداره.
همه با یک حافظه مشترک و شناخت کامل از پروژه.
پروژهای که امروز شاید ۱ میلیون دلار هزینه داشته باشه، میتونه فردا با بخش کوچکتری از هزینه و حتی کیفیت بالاتر ساخته بشه.
نه به این معنی که برنامهنویسها حذف میشن؛ ولی دنیا از شر برنامهنویسهایی که دبه میکنن یا چه بدونم فقط نوک دماغ خودشون رو میبینن خلاص میشه! چون ارزش واقعی از صرفاً کدنویسی کردن به سمت مهندسی، طراحی سیستم و حل مسئله منتقل میشه و شما باید در سطح بسیار بالاتری کار کنی.
نمیخوام دلسرد کنم بعضیها رو اما به نظر من جونیور یا سطوحی که تجربیات معماری و مهندسی ندارن دیگه عملاً در بازار حرفی برای گفتن نخواهند داشت.
شرکتها فقط دنبال این نیستن که چند نفر برنامهنویس استخدام کنن؛ دنبال کسی هستن که بتونه یک سیستم پیچیده رو هدایت کنه و از AI مثل یک تیم کامل مهندسی استفاده کنه و ارزش افزوده رو مدام ارتقاع بده. ارزشافرینی کنه و به عنوان یک مهرهٔ کلیدی حضور داشته باشه.
این چیزیه که همین الآن هم اتفاق افتاده اما به شدت خام هست و هرکسی که بتونه سریع به چنین سطحی برسه سهم خوبی از نیازمندیهای بازار رو به دست خواهد گرفت. 😉
این حرفارو میتونستم نزنم خیلیها هم تو خواب و غفلت بمونن ولی واقعیت اینه جانم، باید بری سمت یاد گرفتن معماری و اصول ساخت و توسعه. چون دیگه چطور بسازم مهم نیست، چرا و با چی بسازم مهمه.
خیلی حرفه که خانوادهٔ مذهبی افراطی بسیار شدید باشی؛ نه دسترسی به ماهواره و رسانههای اونور آبی داشته باشی و نه قدرت خرید اینترنت... چیزی هم که مدام تو مغزت میکنن رسانهٔ داخلی باشه ولی با وجود این شرایط بچهٔ ده سالت بیاد بگه دوس نداشتم تو اون شبها پرچم لبنان فلسطین دستم باشه! آخرش که چی؟! مگه خودمون پرچم نداشتیم...؟!
امان از دست شماها اماااان 😄 من هم سن اینا بودم تو کوچه خاک بازی میکردم هیچی هم از سیاست نمیفهمیدم؛ همین الانشم نمیفهمم ولی شماها کاری کردی که بچه ده ساله هم فهمید چه کلاه گشادی سرش کردین.
شب شیک. 😪
امان از دست شماها اماااان 😄 من هم سن اینا بودم تو کوچه خاک بازی میکردم هیچی هم از سیاست نمیفهمیدم؛ همین الانشم نمیفهمم ولی شماها کاری کردی که بچه ده ساله هم فهمید چه کلاه گشادی سرش کردین.
شب شیک. 😪
به عنوان طرفدار بازی خدای جنگ، انتخاب باتیستا به عنوان شخصیت اصلی سریال خدای جنگ گزینهٔ مناسبی....... نبود!
کریتوس یه شخصیت با چهرهٔ خشن میخواد نه یه دماغ پرچ شدهٔ له و لورده سوسول WWE 😐 حداقل راک رو انتخاب میکردین البته اونم کفتار شده دیگه حال نمیدن... 😔 به نظرم حتی این فوووولاد پسر آقاا خشایار خودمون با کله کچل و ریش بلند گزینهٔ بهتری نسبت به باتیستا بود فقط حیف نیم متر قدشه. 😁😄
ببینیم چی در میاد از سریالش امیدوارم گند نزنه به هرچی تصور در موردش دارم.
کریتوس یه شخصیت با چهرهٔ خشن میخواد نه یه دماغ پرچ شدهٔ له و لورده سوسول WWE 😐 حداقل راک رو انتخاب میکردین البته اونم کفتار شده دیگه حال نمیدن... 😔 به نظرم حتی این فوووولاد پسر آقاا خشایار خودمون با کله کچل و ریش بلند گزینهٔ بهتری نسبت به باتیستا بود فقط حیف نیم متر قدشه. 😁😄
ببینیم چی در میاد از سریالش امیدوارم گند نزنه به هرچی تصور در موردش دارم.
P1000R8_Cpp29_Schedule_FA.pdf
80.2 KB
در مورد نقشهٔ راه استاندارد C++29 یه سوألی بود که آیا ویژگیهایی مثل Networking داخل این ویرایش خواهند بود یا نه؟
قبل از هرچیز باید این رو بدونیم که کارگروه استانداردسازی میگه، صرفاً مهم بودن یک قابلیت تضمین نمیکند وارد C++29 شود؛ باید تا یک برنامهٔ پایان زمانی (deadline) داشته باشد و ویژگی مربوطه واقعاً آمادهٔ استانداردسازی باشد، وگرنه میتواند به C++32 منتقل شود. 😉
مستند «برنامه زمانبندی پیشنهادی استاندارد بینالمللی سیپلاسپلاس» هم به فارسی ضمیمه شد.
مناسب برای کسانی که میخوان بدونن نقشهٔ راه استاندارد بعدی چی هست. 👋🏼
#cpp #isocpp #cppfeatures #pdf
قبل از هرچیز باید این رو بدونیم که کارگروه استانداردسازی میگه، صرفاً مهم بودن یک قابلیت تضمین نمیکند وارد C++29 شود؛ باید تا یک برنامهٔ پایان زمانی (deadline) داشته باشد و ویژگی مربوطه واقعاً آمادهٔ استانداردسازی باشد، وگرنه میتواند به C++32 منتقل شود. 😉
مستند «برنامه زمانبندی پیشنهادی استاندارد بینالمللی سیپلاسپلاس» هم به فارسی ضمیمه شد.
مناسب برای کسانی که میخوان بدونن نقشهٔ راه استاندارد بعدی چی هست. 👋🏼
#cpp #isocpp #cppfeatures #pdf
محو جزئیات برنامهنویسی توی سری جدید سالینت هیل بازی مورد علاقم شدم.
بعد از سالها کونامی تونسته بدون اسطورهٔ اعظم (کوجیما) چیزی خلق کنه که بهش بگی آ باریکلا، این شد یه چیزی 😐 البته بخش بزرگی از این عظمت به خاطر Unreal Engine هست و خب میدونیم که پشت همهٔ اینها چی خوابیده.
https://www.youtube.com/watch?v=ueCeXnq4HOQ
از بعد برنامهنویسی بهش فکر میکنم میبینم، انسجام سیستمها در این نسخه کاری میکنه که جزئیات بهجای تزئین صحنه، جزئی از منطق جهان باشه.
اون رادیو که یکی از اشیاء بسیار پر خاطرهٔ من هست تقریباً توی همه سریهای سایلنت هیل از نسخه ۱ تا به کنون ازش خاطره دارم! و حالا رادیو رو تبدیل کردن به یک ابزار بسیار کاربردی! چطور به ذهنش رسیده توی موجهای رادیو تصویری از حضور دشمناش رو بسازه.
ساختن چنین جزئیاتی حاصل معماریهای ترکیبپذیر و سیستمهای مستقل در موتورهای مدرنه؛ جایی که OOP، Composition و در بعضی بخشها معماریهای Data-Oriented یا ECS میتونن کنار هم قرار بگیرن که قدرت سی++ رو داره به تصویر میکشه.
توی مرجع رسمی راهنمای زبان در قانون C.10 میگه concrete typeها رو به class hierarchy ترجیح بده و صریحاً توصیه میکنه وقتی داشتن یک data member کافی است، بیدلیل inheritance نسازید.
حتی cppreference در بخش Derived Classes درباره Composition میگه استفاده از یک member object معمولاً encapsulation بهتری نسبت به استفاده از inheritance برای این منظور فراهم میکنه.
https://en.cppreference.com/cpp/language/derived_class
و یک منبع آموزشی خیلی سرراست هم از دوره++C دانشگاه Oxford وجود داره که دقیقاً عنوانش Inheritance and Composition است و همین تفاوت
Oxford RSE — Inheritance and Composition in C++
تعریف سادهاش میشه همچین چیزی:
مثلاً به جای اینکه همچین کلاسی داشته باشیم:
که خود کلاس دشمن از کلاس سیگنال ارثبری کنه؛ بهش میگیم دشمن یک قابلیت تولید سیگنال دارد نه اینکه خود دشمن یه سیگنال باشه و رادیو میتونه اون سیگنال رو دریافت کنه.
یعنی همچین چیزی:
اینجاست که میگیم شیء Enemy یک کلاس مشتق شده کلاسیک نیست بلکه متشکل از جزئیات بسیار است مثل
حرکت + جان + هوش مصنوعی + سیگنال
هرکدام یک قطعهٔ جدا هستند و Enemy از ترکیبشان ساخته میشود.
این یعنی همون مفهوم Composition ترکیبسازی.
#cpp #software #oop #ecs #composition
بعد از سالها کونامی تونسته بدون اسطورهٔ اعظم (کوجیما) چیزی خلق کنه که بهش بگی آ باریکلا، این شد یه چیزی 😐 البته بخش بزرگی از این عظمت به خاطر Unreal Engine هست و خب میدونیم که پشت همهٔ اینها چی خوابیده.
https://www.youtube.com/watch?v=ueCeXnq4HOQ
از بعد برنامهنویسی بهش فکر میکنم میبینم، انسجام سیستمها در این نسخه کاری میکنه که جزئیات بهجای تزئین صحنه، جزئی از منطق جهان باشه.
اون رادیو که یکی از اشیاء بسیار پر خاطرهٔ من هست تقریباً توی همه سریهای سایلنت هیل از نسخه ۱ تا به کنون ازش خاطره دارم! و حالا رادیو رو تبدیل کردن به یک ابزار بسیار کاربردی! چطور به ذهنش رسیده توی موجهای رادیو تصویری از حضور دشمناش رو بسازه.
ساختن چنین جزئیاتی حاصل معماریهای ترکیبپذیر و سیستمهای مستقل در موتورهای مدرنه؛ جایی که OOP، Composition و در بعضی بخشها معماریهای Data-Oriented یا ECS میتونن کنار هم قرار بگیرن که قدرت سی++ رو داره به تصویر میکشه.
توی مرجع رسمی راهنمای زبان در قانون C.10 میگه concrete typeها رو به class hierarchy ترجیح بده و صریحاً توصیه میکنه وقتی داشتن یک data member کافی است، بیدلیل inheritance نسازید.
حتی cppreference در بخش Derived Classes درباره Composition میگه استفاده از یک member object معمولاً encapsulation بهتری نسبت به استفاده از inheritance برای این منظور فراهم میکنه.
https://en.cppreference.com/cpp/language/derived_class
و یک منبع آموزشی خیلی سرراست هم از دوره++C دانشگاه Oxford وجود داره که دقیقاً عنوانش Inheritance and Composition است و همین تفاوت
is-a و has-a را درس میدهد. Oxford RSE — Inheritance and Composition in C++
تعریف سادهاش میشه همچین چیزی:
ساختن یک شیء یا سیستم از کنار هم قرار دادن چند جزء مستقل.
مثلاً به جای اینکه همچین کلاسی داشته باشیم:
class Enemy : public Signalکه خود کلاس دشمن از کلاس سیگنال ارثبری کنه؛ بهش میگیم دشمن یک قابلیت تولید سیگنال دارد نه اینکه خود دشمن یه سیگنال باشه و رادیو میتونه اون سیگنال رو دریافت کنه.
یعنی همچین چیزی:
const Enemy enemy;
if (enemy.signal().strength() > 0.5F) {
// Show enemy presence on CRTV.
}
اینجاست که میگیم شیء Enemy یک کلاس مشتق شده کلاسیک نیست بلکه متشکل از جزئیات بسیار است مثل
حرکت + جان + هوش مصنوعی + سیگنال
هرکدام یک قطعهٔ جدا هستند و Enemy از ترکیبشان ساخته میشود.
این یعنی همون مفهوم Composition ترکیبسازی.
#cpp #software #oop #ecs #composition
YouTube
Silent Hill: Townfall - Gameplay Trailer | PS5 Games
SILENT HILL: Townfall set to release on September 24th, 2026.
Pre-Order Now!
Fear the truth behind the static.
Explore the fog-shrouded island of St. Amelia and experience over 18 minutes of atmospheric gameplay from two sections of this brand new entry…
Pre-Order Now!
Fear the truth behind the static.
Explore the fog-shrouded island of St. Amelia and experience over 18 minutes of atmospheric gameplay from two sections of this brand new entry…
COMPΞZ 🧬
توی مرجع رسمی راهنمای زبان در قانون C.10 میگه concrete typeها رو به class hierarchy ترجیح بده و صریحاً توصیه میکنه وقتی داشتن یک data member کافی است، بیدلیل inheritance نسازید.
نوعهای عینی (Concrete Types) را به سلسلهمراتب کلاسی ترجیح دهید!
یک نوع عینی ذاتاً از نوعی که در یک سلسلهمراتب کلاسی قرار دارد سادهتر است.
طراحی آن آسانتر است، پیادهسازی آن آسانتر است، استفاده از آن سادهتر است، استدلال دربارهٔ رفتار آن راحتتر است، حجم کمتری دارد و سریعتر است.
برای استفاده از یک سلسلهمراتب کلاسی باید دلیل مشخص و مورد استفادهٔ واقعی داشته باشید.
اگر یک کلاس بخشی از یک سلسلهمراتب باشد، معمولاً در کد واقعی، هرچند نه لزوماً در مثالهای کوچک مجبوریم اشیای آن را از طریق اشارهگرها (pointers) یا ارجاعها (references) مدیریت کنیم.
این موضوع معمولاً به معنای موارد زیر است:
- سربار بیشتر حافظه
- تخصیص و آزادسازی بیشتر حافظه
- سربار بیشتر در زمان اجرا، بهدلیل دسترسیهای غیرمستقیم (indirection)
یک نوع عینی ذاتاً از نوعی که در یک سلسلهمراتب کلاسی قرار دارد سادهتر است.
طراحی آن آسانتر است، پیادهسازی آن آسانتر است، استفاده از آن سادهتر است، استدلال دربارهٔ رفتار آن راحتتر است، حجم کمتری دارد و سریعتر است.
برای استفاده از یک سلسلهمراتب کلاسی باید دلیل مشخص و مورد استفادهٔ واقعی داشته باشید.
اگر یک کلاس بخشی از یک سلسلهمراتب باشد، معمولاً در کد واقعی، هرچند نه لزوماً در مثالهای کوچک مجبوریم اشیای آن را از طریق اشارهگرها (pointers) یا ارجاعها (references) مدیریت کنیم.
این موضوع معمولاً به معنای موارد زیر است:
- سربار بیشتر حافظه
- تخصیص و آزادسازی بیشتر حافظه
- سربار بیشتر در زمان اجرا، بهدلیل دسترسیهای غیرمستقیم (indirection)
باید در خودت، یک گوشهای از وجودت، آدمی ساخته باشی که در روزهای سخت نیازی به پناه بردن به هیچ کس و هیچ کجا نداشته باشی.
سلام و درود بر هفت جد و خاندانتون!😐
تقریباً الآن ۱ ماه هست روی پروتکل OpenProof کار میکنم، بدون سرو صدا که بخش مهمی از محصولات آیندهٔ ماست و امروز به مرحلهٔ اجرای آزمایشی رسید.
حالا چی هست و چرا ساختمش؟
تقریباً هر محصول نرمافزاری با یک مسئلهٔ مشترک روبهروست: کاربر کیست، چگونه هویتش را اثبات میکند و تا چه حد باید به او اعتماد کرد؟
اوپن پروف یک زیرساخت Identity & Trust مبتنی بر C++26 است که Authentication، OAuth/OIDC، Session، Token، Organization، Policy و Evidence/Trust را در یک معماری واحد ارائه میکند.
هدف OpenProof ساده است:
یک لایهٔ استاندارد، سریع و قابلاعتماد برای مدیریت هویت، اثبات و دسترسی در نرمافزارهای نوین.
در این پروتکل ما نمیگوییم:
بلکه میگوییم:
تقریباً الآن ۱ ماه هست روی پروتکل OpenProof کار میکنم، بدون سرو صدا که بخش مهمی از محصولات آیندهٔ ماست و امروز به مرحلهٔ اجرای آزمایشی رسید.
حالا چی هست و چرا ساختمش؟
تقریباً هر محصول نرمافزاری با یک مسئلهٔ مشترک روبهروست: کاربر کیست، چگونه هویتش را اثبات میکند و تا چه حد باید به او اعتماد کرد؟
اوپن پروف یک زیرساخت Identity & Trust مبتنی بر C++26 است که Authentication، OAuth/OIDC، Session، Token، Organization، Policy و Evidence/Trust را در یک معماری واحد ارائه میکند.
هدف OpenProof ساده است:
یک لایهٔ استاندارد، سریع و قابلاعتماد برای مدیریت هویت، اثبات و دسترسی در نرمافزارهای نوین.
در این پروتکل ما نمیگوییم:
Who's this user?
بلکه میگوییم:
1) Who is this actor?
2) How was it authenticated?
3) What evidence supports that identity?
4) What device is it using?
5) How much should I trust this assertion?
6) Is this operation permissible right now
COMPΞZ 🧬
سلام و درود بر هفت جد و خاندانتون!😐 تقریباً الآن ۱ ماه هست روی پروتکل OpenProof کار میکنم، بدون سرو صدا که بخش مهمی از محصولات آیندهٔ ماست و امروز به مرحلهٔ اجرای آزمایشی رسید. حالا چی هست و چرا ساختمش؟ تقریباً هر محصول نرمافزاری با یک مسئلهٔ مشترک روبهروست: کاربر…
در واقع OpenProof یک زیرساخت یکپارچه برای Identity, Authentication, Trust and Authorization است که بهجای ساختن چندین سیستم پراکنده، هویت، دسترسی و اعتماد را در یک معماری واحد جمع میکند.
این پلتفرم هم OAuth/OIDC و Session/Token را پوشش میدهد، هم ارائه کنندههای مختلف را پشت یک identity مرکزی مدیریت میکند، و هم لایهٔ Evidence/Trust را به تصمیمگیری دسترسی اضافه میکند.
برای مثال احراز هویت چنین ترتیبی داره:
OpenProof Architecture
این پلتفرم هم OAuth/OIDC و Session/Token را پوشش میدهد، هم ارائه کنندههای مختلف را پشت یک identity مرکزی مدیریت میکند، و هم لایهٔ Evidence/Trust را به تصمیمگیری دسترسی اضافه میکند.
برای مثال احراز هویت چنین ترتیبی داره:
OpenProof Architecture
Providers
(Google, Apple, GitHub, Passkey, Wallet, Farcaster, LDAP, SAML)
↓
Trusted Authentication
↓
Canonical Identity
↓
Organizations / Memberships / Roles
↓
OAuth / OIDC / Sessions / Tokens
↓
Evidence & Trust
↓
Policy & Gateway
↓
Secure Access Decision
COMPΞZ 🧬
در واقع OpenProof یک زیرساخت یکپارچه برای Identity, Authentication, Trust and Authorization است که بهجای ساختن چندین سیستم پراکنده، هویت، دسترسی و اعتماد را در یک معماری واحد جمع میکند. این پلتفرم هم OAuth/OIDC و Session/Token را پوشش میدهد، هم ارائه کنندههای…
اگر دقت کرده باشید، من حتی در پروژههایی مثل GenyConnect عمداً هنوز بخش حساب کاربری و احراز هویت را به شکل مستقل پیاده نکردهام. دلیلش ساده است: نمیخواستم هر محصول، سیستم هویت خودش را داشته باشد و دوباره همان مسئله را از صفر حل کند.
هدف این بود که اول یک زیرساخت یکپارچه برای هویت و احراز هویت ساخته شود و بعد تمام محصولات روی همان لایه سوار شوند.
مثلاً اگر کاربری از قبل در اکوسیستم Geny سابقه، هویت یا حساب متصل دارد، یا در پروتکلهایی مثل فارکستر شناخته شده است، نباید برای استفاده از Tegra، CMS، CRM یا هر محصول دیگری دوباره یک حساب و پروفایل کاملاً جدید بسازد و تمام سوابق و هویت او در آنجا از بین برود!
هویت باید قابل حمل باشد، اما سطح دسترسی و نقش کاربر در هر محصول همچنان مستقل و کنترلشده باقی بماند.
این مسئله در ظاهر ساده است، اما در مقیاس سازمانی تبدیل به یکی از پرهزینهترین بخشهای معماری میشود. اگر یک مجموعه ده محصول داشته باشد و هر محصول سیستم Login، Session، Token، MFA، Role، Recovery و Policy خودش را بسازد، عملاً ده بار یک مسئله امنیتی حساس را طراحی، نگهداری و بازبینی کرده است.
اینجاست OpenProof دقیقاً برای حذف همین تکرار ساخته شده است.
بهجای اینکه هر محصول درگیر جزئیات احراز هویت شود، این مسئولیت به یک لایه مرکزی منتقل میشود؛ لایهای که هویت، احراز هویت، اعتماد و دسترسی را بهصورت یکپارچه مدیریت میکند و در عین حال میتواند برای محیطهای مختلف، از اینترنت عمومی تا شبکه داخلی و اینترانت سازمانی، سیاست دسترسی مستقل داشته باشد.
در یک زیستبوم واقعی، کاربر نباید احساس کند که مدام در حال تکثیر هویت خود در محصولات مختلف و جدا شده است. در اصل یک هویت باید او را همراهی کند؛ محصولات فقط باید تصمیم بگیرند در هر نقطه چه دسترسیای دارد.
این همان مسئلهای بود که باعث شد OpenProof را بسازم و ازش راضیم بندهٔ خداااا راضیم! 😎
هدف این بود که اول یک زیرساخت یکپارچه برای هویت و احراز هویت ساخته شود و بعد تمام محصولات روی همان لایه سوار شوند.
مثلاً اگر کاربری از قبل در اکوسیستم Geny سابقه، هویت یا حساب متصل دارد، یا در پروتکلهایی مثل فارکستر شناخته شده است، نباید برای استفاده از Tegra، CMS، CRM یا هر محصول دیگری دوباره یک حساب و پروفایل کاملاً جدید بسازد و تمام سوابق و هویت او در آنجا از بین برود!
هویت باید قابل حمل باشد، اما سطح دسترسی و نقش کاربر در هر محصول همچنان مستقل و کنترلشده باقی بماند.
این مسئله در ظاهر ساده است، اما در مقیاس سازمانی تبدیل به یکی از پرهزینهترین بخشهای معماری میشود. اگر یک مجموعه ده محصول داشته باشد و هر محصول سیستم Login، Session، Token، MFA، Role، Recovery و Policy خودش را بسازد، عملاً ده بار یک مسئله امنیتی حساس را طراحی، نگهداری و بازبینی کرده است.
اینجاست OpenProof دقیقاً برای حذف همین تکرار ساخته شده است.
بهجای اینکه هر محصول درگیر جزئیات احراز هویت شود، این مسئولیت به یک لایه مرکزی منتقل میشود؛ لایهای که هویت، احراز هویت، اعتماد و دسترسی را بهصورت یکپارچه مدیریت میکند و در عین حال میتواند برای محیطهای مختلف، از اینترنت عمومی تا شبکه داخلی و اینترانت سازمانی، سیاست دسترسی مستقل داشته باشد.
در یک زیستبوم واقعی، کاربر نباید احساس کند که مدام در حال تکثیر هویت خود در محصولات مختلف و جدا شده است. در اصل یک هویت باید او را همراهی کند؛ محصولات فقط باید تصمیم بگیرند در هر نقطه چه دسترسیای دارد.
این همان مسئلهای بود که باعث شد OpenProof را بسازم و ازش راضیم بندهٔ خداااا راضیم! 😎
COMPΞZ 🧬
اگر دقت کرده باشید، من حتی در پروژههایی مثل GenyConnect عمداً هنوز بخش حساب کاربری و احراز هویت را به شکل مستقل پیاده نکردهام. دلیلش ساده است: نمیخواستم هر محصول، سیستم هویت خودش را داشته باشد و دوباره همان مسئله را از صفر حل کند. هدف این بود که اول یک زیرساخت…
هستهٔ مرکزی پروتکل با سی++ هست تمام سعیمو کردم تا پایه اساسش از همین ابتدا با بهروز ترین فناوری باشه، از عمق جزئیات گرفته تا تأخیر پایین در درخواستهای بسیار حجیم، سرعت بسیار بالا و راندمان عالی و طبیعتاً مصرف بسیار بسیار بهینهٔ منابع که در حجم سازمانی بسیار هزینهها رو کاهش خواهد داد؛ اما محدود به زبان نیست، خیلی راحت میشه در خروجی زبانهای دیگه روی هر پلتفرمی که هستیم استفاده بشه.
زبانهایی که در توسعش استفاده کردم:
C++ STL (20, 23, 26), Boost, JavaScript
البته برای اولین بار هم به صورت جدی از بوست استفاده میکنم، نخواستم وابستگی به cURL ایجاد کنم؛ مستقیم boost.asio و boost.beast استفاده کردم که بعداً شاید این بخش شبکه رو در استانداردهای C++29 بتونیم روی STL بهروز رسانیش کنیم.
زبانهایی که در توسعش استفاده کردم:
C++ STL (20, 23, 26), Boost, JavaScript
البته برای اولین بار هم به صورت جدی از بوست استفاده میکنم، نخواستم وابستگی به cURL ایجاد کنم؛ مستقیم boost.asio و boost.beast استفاده کردم که بعداً شاید این بخش شبکه رو در استانداردهای C++29 بتونیم روی STL بهروز رسانیش کنیم.
COMPΞZ 🧬
من هیچ فکری در خصوص بازار نمیکنم. 😊 بیشتر از ۹ ماهه حتی یه تراکنش معاملاتی هم نداشتم. کلاً مسیرم یه چیز دیگست، بازار رو میبینم اما نه برای خرید و فروش.
هرجوری بپرسید میذارمش کانال. 😉
هیچ تعارفی با کسی نداریم 😒 اگه قراره سیگنال بدم به همه میدم پارتی بازی هم نداریم.
هیچ تعارفی با کسی نداریم 😒 اگه قراره سیگنال بدم به همه میدم پارتی بازی هم نداریم.