یکی رو سیمون ساخته که از کمیتهٔ استاندارد‌سازیه.
یکیشم خودم ساختم! خوبه از همین استفاده کنید حال کنید.

خوبیش اینه که به فارسی هم درک درستی داره چون از من آموزش دیده. 😎

یک خوبی دیگه اینه که علاوه بر نمونهٔ CMake، آخر کدش توصیه به نسخهٔ سنتی رو هم میده.

اینارو بدین به اون اساتید دانشگاه بی‌سوادتون که حداقل ازاین سی++ ۹۸ بکشن بیرون.

صد ساله خزعبلات آموزش ملت میدن وقتی وارد بازار میشن می‌بینن انگار تازه از غار اومدن بیرون.

ما به خاطر شرایط زندگی، فشار اقتصادی و اوضاع مملکت، خیلی وقت‌ها مجبوریم بگیم:

«بابا زیاد کمال‌گرایی نکن، یه چیزی سرهم کن بیاد بالا، زودتر پول بشه بچسبونیم به درد و بدبختیامون.»

این حرف‌ها تا حدی درسته ولی قوائد مهندسی این چیزا حالیش نیست.

کد شلخته و عجله‌ای یعنی یه نقطهٔ کور توی سیستم درست کردی؛ یه جایی که بعداً نمی‌فهمی با تغییر دادنش چی قراره بترکه.

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

مثلاً اگه فردا سیستم جستجوی تگرا نیاز داشت کامل عوض بشه، نباید مجبور بشیم کل CMS رو زیر و رو کنیم. وقتی معماری درست باشه، همون بخش رو جدا تغییر می‌دی، تست می‌کنی، جایگزین می‌کنی و بقیهٔ سیستم هم سر جاش می‌مونه.

مثل موتور ماشینه؛ اگه مشکل از پیستونه، باید بتونی همون قطعه رو عوض کنی، نه اینکه کل موتور رو باز کنی بندازی زمین فقط برای یه ایراد مشخص.

این کمال‌گرایی نیست؛ این اصول معماریه.

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

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

این چیزارو باید کرد تو مغز اونی که با AI هوا هوا می‌کنه فکر می‌کنه چون یه خروجی گرفته پس شده طراح!
والاما سال‌ها درسشو باید بخون اینطوری نیست که چون یه چیزی اجرا میشه پس مناسبِ یک محصول شدن هست.

ببخشید ولی کم پُز کدهای شلخته‌پلخته بدین باهاش محتوا درست کنید که بیابگم چطوری اینو بسازی! چقدر محتوای چرند آخه؟ هرچند بازار با همین چرندیات بازاره‌ها... ولی خب آینده‌نگری هم لازم است.

کدهایی که می‌نویسد، اگه مهندسی نباشن اکثر مواقع یک ریال هم ارزش ندارن! حالا بماند اون بدبختی که پول میده بهش رو چطور خر فرض کردین، بیچاره مشتری...

دستم خورد کل GPT برای سی++ رو حذف کردم! نه پیامی نه هشداری!!!

هیچ راه بازیابی نداشت مجبور شدم مدل رو دوباره بسازم!

لینک جدید:

https://chatgpt.com/g/g-6a4a5321aa6c81919db8ad13b87530d8-modern-c

یکم باهاش چت کنید توی فهرست بیاد بالا 😑

در کل این GPT App چیز خوبیه! به عنوان استاد یا کسی که می‌تونید آموزشی بدین می‌تونید مدل رو آموزش بدین بقیه ازش سوال کنن!

عین یه منتور :) چیزای جالبی دارم پیدا می‌کنم.

امروز بخش مدیریت زبان و محتوای تگرا کمی پیچیدگی داشت! چون یکی از مهم‌ترین بخش‌های مدیریت محتواست.

خبر خوش اینکه از همون نسخهٔ ابتدایی زبان‌ها رو بر مبنای استاندارد پشتیبانی می‌کنه.

این ویژگی به عنوان یک بخش مهمی از هستهٔ سیستم هست که اجازه میده بخش‌های مختلف رو روی ترجمه مدیریت کنه:

۱) محتوای درون بانک اطلاعاتی، مثل خبر، لینک، عنوان، موضوع یا هر چیزی.
۲) محتوای درون سیستمی، مانند استثناء‌ها، پیام‌ها یا هر چیزی که به عنوان یک پیام از سمت سیستم ساطع می‌شه.
۳) پشتیبانی از هوش مصنوعی و مدل مشخص (سفارشی شده) در بخش مدیریت که اجازه خواهد داد در کمترین زمان مملکن محتوا رو به زبان مورد نظر ترجمه کنه.

هر سه بخش به ترتیب از روی لینک‌های درون سیستمی تحت فایل json تجزیه می‌شن و محتوا در درون جداول دیتابیس مربوط به هر ماژول نگه‌داری می‌شه.

یک موردی هم که در نظر دارم پشتیبانی از سیستم هوشمند صوتی هست و پوشش دادن یک سری محتوا مختص نابینایان و نا شنوایان. این بخشش پیچیدست ولی توی برنامه خواهیم داشت.

ساختار سادست، فرض بگیریم چنین کدی خواهیم داشت:

auto key = MessageKey::parse("content.slug.conflict");

این درون سیستم به هیچ محتوا یا متن صریحی اشاره نداره، صرفاً یک کلید دسترسی به یک رشتهٔ مشخص در مسیر مشخصه.

سیستم صد در صد به صورت پویاست.

ساختار فایل JSON:

{
  "content": {
    "slug": {
      "conflict": "The slug \"{slug}\" is already used."
    }
  }
}

نمونه مسیری از ساختار فایل‌های ترجمه:

locales/
  en/
    core.json
    content.json
  fa/
    core.json
    content.json

مثال از ساختار هدایت کننده در پیوند‌ها:

eng
en
fa
per
fa-IR
en-US
en-us
zh-Hant-TW

https://yourwebsite.com/en-us/news
https://yourwebsite.com/fa-ir/news
https://yourwebsite.com/fa-ir/خبر
https://yourwebsite.com/fa-ir/دربارهٔ-ما

این موضوع در بحث SEO سازی به زبان موقعیت جغرافیایی و زبان سیستم مهمه.
همچنین رشته‌ها به یونیکد ترجمه می‌شن تا از نظر زبان انسانی قابل درک‌تر باشه؛ هرچند در پس زمینه به کد‌های سطح پایین‌تر تبدیلشون می‌کنم.

گفتم که درستش می‌کنم! 😎 بچم‌ برگشت تو لیست. 🫡

حالا دیگه مشکل عدم نمایشی روی وارپلت نداره.

این هم نمونه‌ای از نحوه‌ٔ ادغام داده‌های بک‌اند با قالب‌های فرانت‌اند در Tegra CMS.

سعی کردم سینتکس قالب‌نویسی چیزی شبیه Django باشد؛ ساده، قابل فهم و تمیز.

ایده اینه که بک‌اند داده‌ها را آماده می‌کند، سپس Template Engine آن داده‌ها را با HTML ترکیب می‌کند و خروجی نهایی صفحه ساخته می‌شود.

در این مدل می‌توانیم فایل‌های جداگانه مثل header یا footer را include کنیم، شرط بگذاریم، روی لیست‌ها loop بزنیم، متغیرها را داخل HTML نمایش دهیم و حتی کامنت‌های مخصوص template داشته باشیم که در خروجی نهایی HTML ظاهر نمی‌شوند.

هدفم این بوده که لایه‌ٔ قالب‌نویسی هم ساده باشد، هم امن، هم قابل نگهداری؛ بدون اینکه تبدیل به یک زبان برنامه‌نویسی کامل و پیچیده داخل HTML شود.

به زبان ساده یعنی:

۱) بک‌اند سمت ++C داده را می‌سازد.
۲) قالب (موتور قالب‌سازی سمت ++C) آن را نمایش می‌دهد.
۳) خروجی نهایی، HTML تمیز و قابل کنترل است.

برای CMS این بخش پایهٔ یک سیستم رندرینگ سبک، قابل توسعه و شبیه Django-style template engine هست هرچند من به دنبال یک مدل قوی‌تر نسبت به نمونه‌هایی هستم که قبلاً تجربش کردم.

سوأل جالبی بود!

خب جنی بر پایهٔ شبکهٔ Base هست (با کمترین کارمزد و سریع‌ترین تراکنش) و کاملاً غیر متمرکزه!

هیچ وابستگی‌ای هم به فارکستر نداره (فارکستر فقط یه شبکه اجتماعی غیرمتمرکزه که تمام سعیمون اینه که باهاش ادغام بشه).

هر پلتفرمی که غیرمتمرکز باشه اینو پشتیبانی می‌کنه.

https://basescan.org/address/0x2a3d6f8c1fc4AcDcf3A75d19b445bae02F03676B

استخرش رو اون زمان روی Uniswap v4 بالا آوردم.

https://app.uniswap.org/explore/tokens/base/0x2a3d6f8c1fc4AcDcf3A75d19b445bae02F03676B

قبل از هر چیز باید روی صرافی coingecko لیستش کنم به وقتش.

امروز یه تماسی داشتم که متوجه شدم یه سری قوانین جدی‌تر شده که در مراحل ثبت شرکت‌ها و معرفی کسب‌و‌کار‌ها نام‌دامین و آدرس ایمیل سازمانی ظاهراً ضروری هست.

یاد‌آوری کنم برای هم صنف‌های خودم؛ وقتی برای مشتری سایت یا دامنه بالا میارید، این‌قدر شرف داشته باشید که مالکیتش رو به اسم خودتون ثبت نکنید.

این دقیقاً مثل اینه که من برم ماشین بخرم، پولشم کامل بدم، ولی سند ماشین بخوره به اسم فروشنده!

همین که مسئول فنی کار باشید کافیه.
مسئول فنی یعنی کارای فنی، تنظیمات، پشتیبانی و نگهداری؛ نه اینکه صاحب مال مردم بشید.

این رو هم به آدم‌های کم‌تجربه بگید:
دامنه شوخی نیست. هر کسی دامنه رو با شناسهٔ خودش ثبت کنه، عملاً صاحب امتیاز همونه، مگر اینکه اطلاعات مالک واقعی درست وارد شده باشه.

توی ثبت دامنه معمولاً چندتا نقش جدا داریم:

یکی صاحب امتیازه؛ یعنی مالک واقعی دامنه.
یکی رابط مالیه؛ یعنی کسی که پرداخت و تمدید رو پیگیری می‌کنه.
یکی رابط فنیه؛ یعنی کسی که تنظیمات و کارای فنی رو انجام می‌ده.
یکی هم رابط اداریه؛ یعنی پیگیری‌های ثبتی و اداری.

پس اگه برای مشتری دامنه ثبت می‌کنید، درست و شفاف بهش بگید مالک کیه، رابط فنی کیه، رابط مالی کیه.

خیلی دیدم آدم‌هایی رو که از ناآگاهی مشتری سوءاستفاده کردن؛ دامنهٔ طرف رو به اسم خودشون ثبت کردن به بهونهٔ این که خب من برات ثبت کردم، بعداً هم با همون چیزی که مال خود مشتری بوده، ازش پول اضافه خواستن یا روش فشار آوردن.

این دیگه اسمش زرنگی نیست.
اسمش دزدیه.

اگه مال مردم رو به اسم خودتون ثبت می‌کنید و بهش نمی‌گید، شما طراح سایت یا مسئول فنی نیستید؛ دزدید!

دیدم که می‌گم‌ها... چند صد تا دامین طی اینهمه سال برای مشتریام ثبت کردم همیشه هم بهشون گفتم ببین بیا به اسم خودت ثبت کنم! حتی طرف حوصله نداشته می‌گفته من بلد نیستم تو برام ردیفش کن! همینجاست که بنده خدا نمی‌دونه همین حرفش یعنی دو دستی اختیار دامینش رو به یکی دیگه دادن.

شاید توی کارها یا وب‌سایت‌های ساده مهم نباشه بگیم خب بابا چیزی نداره که! اما من دیدم طرف دامین ۳ هزار تومنی رو ۱۰ سال پیش چطور به قیمت اون موقع ۱ میلیون گرفت و کرد تو پاچهٔ مشتریش که فقط تمدید ازش می‌خواست!

این پول‌ها خوردن نداره... همون شخص احتمالاً الآن داره هندونه می‌فروشه به جای طراحی وب‌سایت.
آدم باشیم! اعتبار اونطوری که شما فکر می‌کنید به دست نمیاد.