COMPΞZ 🧬
اینوووو 🤣😆 خووووب بود!😆 هکر باحالیه در اصل استاد SEO خوبیام هست. 👌🏼
جالب بودنش به کنار، اما برای همچین مسائلی بهترین کار اینه با هزینهٔ کمتر مشکل ایمنی وبسایت رو حل کنید اونم تازه اگه اسرائیلی باشه خب پیداش کردی میخوای چیکارش کنی؟ 😄
یک میلیارد حالا حتی به تومان هم باشه ارزش پیدا کردن اینو نداره.
روشش عالی بود ولی 🤣👌🏼 اینو باید پیدا کرد ازش یاد گرفت، ببین این دیگه کی بوده که سئو رو جعل کرده که کوگل سایتو از بیخ زده. 😬
یک میلیارد حالا حتی به تومان هم باشه ارزش پیدا کردن اینو نداره.
روشش عالی بود ولی 🤣👌🏼 اینو باید پیدا کرد ازش یاد گرفت، ببین این دیگه کی بوده که سئو رو جعل کرده که کوگل سایتو از بیخ زده. 😬
COMPΞZ 🧬
جالب بودنش به کنار، اما برای همچین مسائلی بهترین کار اینه با هزینهٔ کمتر مشکل ایمنی وبسایت رو حل کنید اونم تازه اگه اسرائیلی باشه خب پیداش کردی میخوای چیکارش کنی؟ 😄 یک میلیارد حالا حتی به تومان هم باشه ارزش پیدا کردن اینو نداره. روشش عالی بود ولی 🤣👌🏼 اینو…
برای خودم جالب شد، روی تگرا یه بستهٔ امنیتی پیاده کنم که تمرکز روی ایمنی سئو رو هم تضمین کنه و چه باحال باشه وقتی سیستم کامپایلریه. 🙃
اگه همچین مشکلاتی برای سایتتون پیش اومد مواردی که میتونید بررسی کنید کم نیستن.
هکر احتمالا از روشهای متعددی آزمایش گرفته و حفرهٔ امنیتی میتونه توی یکی از روشهای رایج باشه که درنهایت دستکاری sitemap.xml شکل میگیره.
روشش یکی دو تا هم نیست، از sql injection ساده گرفته تا حتی حمله به SSTI، SCSS و کلی روشهای دیگه.
حداقل ۲۰/۳۰ تا مورد برای نفوز جهت تغییر شاخصهای سئو وجود داره که باید بهشون توجه بشه.
یه متخصص وب باید به اینا دقت کنه، صرفا یه وردپرس نصب کردن برای داشتن یه وب سایت ملاک نیست هرچند CMS خودش باید این چیزارو هم تضمین کنه.
مبحث CMS کلی داستان داره یکی از مهمترین بخشهاش template engine هست که به شدت باید ایمن باشه یا حتی مهمتر از سیستم مدیریت محتوا، پیکربندی درست وبسرور مهمه مثل آپاچی، انجین ایکس و … ممکنه با سادهترین دسترسی تزریق ممکن بشه و این مسائل روی سیستمهای اسکریپتی عین آب خوردنه.
خندم به این میگیره که از این پس هرکی که با ai خواست سایت بسازه بنده خدا در جریان این مسائل نیست که بدونه چه بلاهایی ممکنه سرش بیاد! زیاد طول نمیکشه یه مدت بعد متوجه میشید که تخصص مهمه نه صرفا ابزار!!!
اگه همچین مشکلاتی برای سایتتون پیش اومد مواردی که میتونید بررسی کنید کم نیستن.
هکر احتمالا از روشهای متعددی آزمایش گرفته و حفرهٔ امنیتی میتونه توی یکی از روشهای رایج باشه که درنهایت دستکاری sitemap.xml شکل میگیره.
روشش یکی دو تا هم نیست، از sql injection ساده گرفته تا حتی حمله به SSTI، SCSS و کلی روشهای دیگه.
حداقل ۲۰/۳۰ تا مورد برای نفوز جهت تغییر شاخصهای سئو وجود داره که باید بهشون توجه بشه.
یه متخصص وب باید به اینا دقت کنه، صرفا یه وردپرس نصب کردن برای داشتن یه وب سایت ملاک نیست هرچند CMS خودش باید این چیزارو هم تضمین کنه.
مبحث CMS کلی داستان داره یکی از مهمترین بخشهاش template engine هست که به شدت باید ایمن باشه یا حتی مهمتر از سیستم مدیریت محتوا، پیکربندی درست وبسرور مهمه مثل آپاچی، انجین ایکس و … ممکنه با سادهترین دسترسی تزریق ممکن بشه و این مسائل روی سیستمهای اسکریپتی عین آب خوردنه.
خندم به این میگیره که از این پس هرکی که با ai خواست سایت بسازه بنده خدا در جریان این مسائل نیست که بدونه چه بلاهایی ممکنه سرش بیاد! زیاد طول نمیکشه یه مدت بعد متوجه میشید که تخصص مهمه نه صرفا ابزار!!!
COMPΞZ 🧬
اینوووو 🤣😆 خووووب بود!😆 هکر باحالیه در اصل استاد SEO خوبیام هست. 👌🏼
چه جالب! متوجه شدم صاحب اون سایت که هکر اونطوری هکش کرده یه چپوله! 😆 میگم آخه یه دلیلی باید باشه و اگرنه مسخرست!
یعنی قشنگ هم از اونور هم از اینور دست به دست دادن همه چیرو توجیه کنن که ما خوب بودیم! ما که میدونیم ترستون از چیه. 😉
حالا جوابتو من بدم؟ مصدق چه بود که بود؟ مصدق هم عین شماها یه نفهم خود مظلوم نمای چپول بود که هیچوقت نفهمید و شماهاهم هیچوقت نخواهید فهمید، دو تا مستند ازش بذاری روی میزت خواهی فهمید که بزرگترین خیانتها رو امثال این بشر به این ملت کرد.
ولی میدونی شما دو طرفه هم قدرت داری و هم رسانه و هم پول اما با این حال اونی که باید بفهمه میفهمه شماها چه جونورهای سمیای هستین!
یقهها رو با کراوات تزئین میکنید خودتونو از عرزشیا جدا میدونید و خیلی آگاه و با سواد! اما ذاتتون کثافته.
اتفاقا من به خیلی از عرزشیای مردمی امید دارم چون اینا حداقل از روی سادگی و باورهاشون طبیعیه حماقت کنن! اما شماها روباهید روباه!!! روباههای مکار مظلومنمایی که خائن به وطنید سرو ریشه هر کدومتونم بزنن میرسن به زندگیهای لاکچری اونور آبی ضد ایرانی که اشک تمساح میریزید و همیشه خنجر از پشت میزنید.
یعنی قشنگ هم از اونور هم از اینور دست به دست دادن همه چیرو توجیه کنن که ما خوب بودیم! ما که میدونیم ترستون از چیه. 😉
حالا جوابتو من بدم؟ مصدق چه بود که بود؟ مصدق هم عین شماها یه نفهم خود مظلوم نمای چپول بود که هیچوقت نفهمید و شماهاهم هیچوقت نخواهید فهمید، دو تا مستند ازش بذاری روی میزت خواهی فهمید که بزرگترین خیانتها رو امثال این بشر به این ملت کرد.
ولی میدونی شما دو طرفه هم قدرت داری و هم رسانه و هم پول اما با این حال اونی که باید بفهمه میفهمه شماها چه جونورهای سمیای هستین!
یقهها رو با کراوات تزئین میکنید خودتونو از عرزشیا جدا میدونید و خیلی آگاه و با سواد! اما ذاتتون کثافته.
اتفاقا من به خیلی از عرزشیای مردمی امید دارم چون اینا حداقل از روی سادگی و باورهاشون طبیعیه حماقت کنن! اما شماها روباهید روباه!!! روباههای مکار مظلومنمایی که خائن به وطنید سرو ریشه هر کدومتونم بزنن میرسن به زندگیهای لاکچری اونور آبی ضد ایرانی که اشک تمساح میریزید و همیشه خنجر از پشت میزنید.
COMPΞZ 🧬
چه جالب! متوجه شدم صاحب اون سایت که هکر اونطوری هکش کرده یه چپوله! 😆 میگم آخه یه دلیلی باید باشه و اگرنه مسخرست! یعنی قشنگ هم از اونور هم از اینور دست به دست دادن همه چیرو توجیه کنن که ما خوب بودیم! ما که میدونیم ترستون از چیه. 😉 حالا جوابتو من بدم؟ مصدق…
سه دسته نفهم داریم!
نمیتونه بفهمه.
نباید بفهمه.
دوست داره نفهمه.
نمیتونه بفهمه.
نباید بفهمه.
دوست داره نفهمه.
وقتی بعضیها یه برنامه رو دو روزه با AI میسازن و فکر میکنن حله یا در بهترین حالت فکر میکنن بخش احراز هویت یعنی یه جدول user و یا چهارتا فیلد و فوقش یه API و JWT... ما از روی حماقت نه از روی اهمیت دادن به معماری، خودِ احراز هویت رو یه پروژه میبینیم. 😁
این قراره بخشی از هستهٔ یک پروژهٔ وطنی باشه. صدها هزار خط کد با یک معماری فوق پیشرفته برای پشتیبانی از هر نوع احراز هویت داخلی و خارجیه.
از یک حساب کاربری ساده گرفته تا برو پروتکلهای متنبی بر بلاکچین.
این قراره بخشی از هستهٔ یک پروژهٔ وطنی باشه. صدها هزار خط کد با یک معماری فوق پیشرفته برای پشتیبانی از هر نوع احراز هویت داخلی و خارجیه.
از یک حساب کاربری ساده گرفته تا برو پروتکلهای متنبی بر بلاکچین.
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