COMPΞZ 🧬

سوألی هست که وقتی دراگون هست چرا ازش استفاده نمی‌کنی برای ساختن CMS‌ات؟ چون من تمایلی ندارم وابستگی چینی توی قلب سیستمم باشه. همشونو من قبلاً آزمایش کردم به دلم نمی‌شینن. بهترین ویژگی فریم‌ورک وب دراگون اینه که non-blocking I/O هست که تگرا مشابه همون مکانیزم و حتی بهترشو پشتیبانی می‌کنه غیر اون مابقی مواردش کار سختی نیست! تگرا الآن هم از multi-thread پشتیبانی می‌کنه و روی پردازنده‌های چند هسته‌ای کار می‌کنه هم از non-blocking I/O پشتیبانی می‌کنه. به زبان ساده‌تر بخوام بگم این یعنی چی؟ یعنی در مدل blocking، اگر یک درخواست منتظر پاسخ دیتابیس بماند، همان thread (رشته) عملاً معطل می‌شود. اما در مدل non-blocking، سیستم می‌گوید: «تو منتظر بمان؛ من در همین فاصله کارهای دیگر را انجام می‌دهم.» این یعنی مصرف بهتر CPU، توان پاسخ‌گویی بالاتر، latency کمتر، و معماری مناسب‌تر برای ترافیک زیاد. وقتی multi-threading و non-blocking I/O کنار هم قرار می‌گیرند، نتیجه این می‌شود که سیستم هم از قدرت چند هستهٔ CPU استفاده می‌کند، هم رشته‌ها را با انتظارهای بیهوده هدر نمی‌دهد. این دقیقاً همان چیزی است که برای یک CMS مدرن، سریع، کم‌مصرف و مقیاس‌پذیر نیاز داریم.

خب بله! برای اطمینان یه حساب جدید ساختم؛ احراز هویت می‌خواد. اما یه نکتهٔ جالب داشت! نام Iran توی فهرست هست و خیلی‌ها فکر می‌کنن این یعنی تحریم نیست! انجامش که بدی می‌گه: We cannot accept this ID typ.e Please choose an accepted ID. حالا یه سوأل از اونی که فکر می‌کنه اینا دوست مردم ایرانن؟ اینو زمان جنگ وقتی اون کله زرد می‌گفت عن‌گانی در راه است به یه سری‌ها گفتم که ببین اینا حرفه! اینکه یه سیستم بذاره کارت ملی مردم رو اسکن کنه ببینه که من یه شهروند عادی هستم یا یه نظامی؟ با توجه به تحقیقاتم همچین چیزی متوجه شدم: تفکیک فردی شدنی است. KYC دقیقاً برای همین ساخته شده: سند هویتی، چهره، شماره، محل اقامت، ریسک حقوقی، لیست تحریم، PEP، watchlist و سابقهٔ رسانه‌ای/حقوقی. حتی خود OFAC ابزار Sanctions List Search دارد که برای تطبیق نام با لیست‌های تحریمی استفاده می‌شود. اما شرکت‌هایی مثل Anthropic معمولاً یک لایهٔ بالاتر تصمیم می‌گیرند: کشور پشتیبانی‌شده یا پشتیبانی‌نشده در صفحهٔ رسمی Anthropic، ایران جزو کشورهای پشتیبانی‌شدهٔ Claude نیست؛ و خود Claude هم احراز هویت را از طریق Persona انجام می‌دهد، یعنی از نظر فنی ابزار شناسایی فردی وجود دارد، ولی سیاست نهایی می‌تواند همچنان country-level باشد. خب اینجاست که باید بپرسم از همان‌هایی که می‌گفتند: «این‌ها با مردم ایران مشکلی ندارند.» «این‌ها دوست ما هستند.» «این‌ها آمده‌اند مردم را نجات بدهند.» خب اگر دوست مردم‌اند، چرا همین تفکیک ساده را انجام نمی‌دهند؟ اگر می‌توانند با دقت نظامی بفهمند چه کسی کجاست، چه کسی وابسته به کجاست، چه کسی هدف است و چه کسی نیست، چطور نمی‌توانند بفهمند من یک شهروند عادی‌ام یا یک فرد سیاسی و نظامی؟ سخت است؟ نه. غیرممکن است؟ قطعاً نه. فقط برایشان به‌صرفه‌تر است که فرق نگذارند. چون در نگاه آن‌ها، شهروند عادی ایرانی هم بخشی از همان ریسک کلی است. نه به خاطر کاری که کرده؛ فقط به خاطر جایی که به دنیا آمده. پس مسئله فقط تحریم نیست. مسئله این است که جهانِ قدرتمند، ترجیح می‌دهد ما دسترسی نداشته باشیم، ابزار نداشته باشیم، رقابت نکنیم، رشد نکنیم و همیشه پشت در بمانیم. 😝

پنجم اینکه از GenyConnect استفاده کنید تا کام‌روا شوید.

این Fable 5 هم اونطور که می‌گن غولِ نمی‌دونم چیچیه... نه والا شما پرامپتت خوب باشه بفهمی چی می‌نویسی همون اپوس هم خوبه. تنها مزیتش اینه که به خاطر بهتر بودن درکش نسبتاً توکن کمتری مصرف میکنه. ولی اینکه می‌گن به جای کلاد از Antigravity یا امثالش استفاده کنید، خداشون هم فرق میکنه چه برسه کیفیت درک و شعورشون. کلاد ساخته شده برای برنامه‌سازی، تحلیل، ممیزی، شخم زدن یه پروژه! بقیه موارد مونده تا به پای این برسن.

می‌بینم که دونه دونه حساب‌های Claude ایرانی‌ها به چوخ میره! خب چند تا توصیه دارم! اول اینکه تا روشن شدن تکلیف این موضوع احراز هویت کاری باهاش نداشته باشید! هزینه نکنید، نخریدش! دوم اینکه، به هیچ عنوان از داخل سیستم خودتون حتی با VPN ورود نزنید، چون هر vpn ای ویپی‌ان نیست، نشتی داشته باشه موقعیت شما رو لومیده. سوم اینکه، برای مصارف شرو ور یا چت‌های روزانه ازش استفاده نکنید، باهاش فارسی نویسی نکنید! چهارم اینکه، یه سرور با موقعیت آمریکا بخرید و از داخل سرور آمریکا نسخهٔ CLI رو نصب کنید و از سیستم خودتون بهش ریموت ssh بزنید. نکته) اگه نیاز به خرید سرور آمریکا داشتین، با دریافت هزینهٔ منصفانه من این کار رو براتون انجام میدم. هم سرورشو هم کارت اعتباریشو می‌خرم و روش هم یه شبکه خصوصی واستون راه‌اندازی میکنم. وسلام علیکم و تبارک الله اعظمی! 😌

شادروان شاعر حیدر یغما می‌گه: تنم در وسعت دنیای پهناور نمی‌گنجد؛ روان سرکشم در غالب پیکر نمی‌گنجد.

و باز هم می‌رسم به تأکید بر مثلث دانش. 👋🏼 چیز‌هایی هستند که ما نمی‌دانیم که نمی‌دانیم. هوش مصنوعی این فرصت رو به شما میده که بتونی به همین چیز‌هایی که نمی‌دونی بیشتر فکر کنی.

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

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

سوأل پر تکرار و مهم این روز‌ها. آیا برنامه‌نویسی به واسطهٔ هوش مصنوهی از بین میره؟ از نظ من که میلیون‌ه خط کد نوشتم؛ برنا‌مه نویسی چیز قابل حذفی نیست؛ این یک مهارت از درک، تفسیر و تبدیل ذهن به دستورالعمل‌های قابل درک توسط کامپیوتر هست؛ اما کد نویسی به عنوان یک لایهٔ فرساینده و وقت‌گیر قطعاً حذف میشه و بیشتر می‌ره سمت طراحی سیستم و معماری چیزی که بهش می‌گیم دانش. ارزش اصلی برنامه‌نویس دیگه تعداد خط کدی که می‌نویسه نیست، بلکه درک معنا و مفهومش هست. کدنویسی در اصل یک لایه بین ذهن انسان و ماشین به حساب میاد؛ یعنی ما ایده، منطق و معماری رو به زبانی تبدیل می‌کنیم که کامپیوتر بفهمه. حالا هوش مصنوعی داره بخش بزرگی از همین لایهٔ رو حذف می‌کنه! خب چه چیزی بهتر از این؟ از چی می‌ترسید؟ 😄 از خداتونم باشه بابا تا دیروز به خاطر تایپ کردن انگشت‌درد، سردرد، گردن درد، همه چی درد داشتیم الآن از این به بعد بیشتر می‌تونی به سلامتت فکر کنی بیشتر فکر کنی به جای اینکه بیشتر تایپ کنی.

حذف شدنِ تایپ کردن کد، به معنی حذف شدن مهندسی نرم‌افزار نیست. شما باید بدونید معماری چیست! فکر کردن به مسأله و روش حل مسأله.

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

✔ از وقتی از AI خواستم واسم وضعیت پروژه رو مستند کنه کارم خیلی راحت‌تر شده! 👌یعنی 10000X S Max Plus در نظر بگیر! 😄 قبلاً ذهنم همش درگیر این بود که خدایا کجا چیرو جا انداختم! فلان چیز یادم نره، بهمان چیز یادم نره... فلان تابع یا فلان کد مشکل داشت اصلاح کردم یا نکردم... یه پرامپت نوشتم با Fable 5 که به صورت یک اسکریپت شِل هربار بعد از تغییرات کل پروژه رو شخم می‌زنه الآن هربار کامیت میزنم خودکار به‌روز رسانی وضعیت می‌کنه در فاز‌ها رو خیلی تمیز مستند می‌کنه در بخش‌های مختلف بهم می‌گه که در چه وضعیتی هستیم. همینه! دستیار و کارآموز خوب یعنی همین. 👊🏼

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

این باگ فارکستره! نگران توکن‌هاتون نباشید. https://farcaster.xyz/compez.eth/0xad91095e بهشون گزارش هم دادم باگه جنی نیست، باگه فارکستره. ✔️ برای اطمینان از دیبانک بررسی کنید:

https://debank.com/profile/{yourwallet_address}

از همه جالب‌تر اینکه چنین سیستم‌هایی عموماً با زبان‌های اسکریپتی مثل PHP ساخته می‌شن، نه با یک زبان کامپایلری و خروجی باینری. حالا فرض کنیم یک سیستم مدیریت محتوای جدی، پیچیده و قابل توسعه، به جای اینکه روی مدل رایج اسکریپتی ساخته بشه، با یک زبان کاملاً کامپایلری شکل بگیره؛ نتیجه چه خواهد شد؟ خب موضوع فقط «سرعت» نیست! وقتی یک CMS به شکل باینری اجرا می‌شه، می‌تونه مصرف منابع بسیار بسیار پایین‌تری داشته باشه، فشار کمتری به سرور وارد کنه، چیزی که الآن به خاطرش کلی هزینه صرف می‌کنن! با حافظه و پردازنده بهینه‌تر رفتار کنه، هزینهٔ میزبانی رو کاهش بده و در مقیاس بالا انرژی کمتری مصرف کنه و بره در فهرست مصارف انرژی سبز. از نظر امنیت هم یک تفاوت جدی وجود داره؛ در مدل‌های اسکریپتی، بخش زیادی از منطق سیستم به صورت فایل‌های قابل خواندن و تغییر روی سرور وجود داره و موجب راحتی نفوذ و هک در سیستم میشه. اما در یک سیستم کامپایل‌شده، خروجی نهایی می‌تونه کنترل‌شده‌تر، سخت‌تر برای دستکاری مستقیم، و مناسب‌تر برای معماری‌های امن باشه. از طرف دیگه، چنین انتخابی بدون هزینه نیست. ساخت CMS با یک زبان کامپایلری سخت‌تره، داناش بالا‌تری می‌خواد و توسعه‌اش پیچیده‌تره. build system، dependencyها، deployment، سازگاری با سرورها، extension system، pluginها، hot reload، migration و تجربهٔ توسعه‌دهنده نیاز به طراحی بسیار دقیق‌تری دارن. من قبل از اینکه استاد ++C باشم؛ برای سال‌ها تسلط خوبی در PHP داشتم و می‌دونم در چنین زبان‌های اسکریپتی، کاربر فایل رو آپلود می‌کنه، تغییر می‌ده، رفرش می‌کنه و نتیجه رو می‌بینه. خب این خیلی ساده و جالبه! اما در یک سیستم باینری، همه‌چیز باید مهندسی‌شده‌تر باشه، از نصب و به‌روزرسانی گرفته تا ماژول‌ها، افزونه‌ها، قالب‌ها و ارتباط با دیتابیس. اما همین سختی، اگر درست حل بشه، تبدیل به قدرت عجیبی می‌شه به خصوص وقتی صحبت حساسیت و ایمنی در وب‌سایت‌های حوزهٔ وب ۳ میشه. این یعنی کاربر می‌تونه همچنان تجربه‌ای ساده داشته باشه، اما پشت صحنه یک موتور سریع، امن، بهینه و کامپایل‌شده در حال کار باشه و مسائل مربوط به ریسک‌ها به حداقل ممکن برسه. مزیت‌ها روشنه: سرعت بالاتر، مصرف منابع بسیار کمتر، هزینهٔ میزبانی بسیار پایین‌تر، ایمنی خارق‌العاده، کنترل بهتر در زمان اجرا، پایداری بیشتر در زمام اجرا، و امکان ساخت یک هستهٔ قدرتمندتر برای آینده. معایبش هم حقیقتاً: پیچیدگی توسعه بوده که برای همین هم مدت زیادی طول کشیده تا بتونم سیستم باز سازی کنم. آیندهٔ CMS فقط این نیست که محتوا رو مدیریت کنه؛ باید زیرساخت، امنیت، توسعه، هوش مصنوعی، هزینه، مصرف انرژی و تجربهٔ راه‌اندازی رو هم مدیریت کنه. خودم بخوام کل این ماجرا رو خلاصه کنم در یک کلام می‌گم:

Super High-End.

واسهٔ همینه توی شعار‌هام همیشه گفتم:

C++ is not a language for people who only want quick results. It is a language for people who want to create things that seem impossible.

بخش مهمی از تجربهٔ من در ساخت چنین سیستمی، فقط به خاطر آشنایی یا تسلط به مفهوم کلی «سیستم مدیریت محتوا» نیست. سال‌ها یک سیستم مدیریت بسیار پیچیدهٔ آمریکایی و جدی مثل Invision Power Board رو بررسی کردم، تحلیل کردم، تجزیه کردم و از نزدیک فهمیدم چنین سیستم‌هایی چقدر لایه، جزئیات، منطق و معماری پشت خودشون دارن. ساخت یک CMS واقعی فقط این نیست که چند صفحه، چند جدول دیتابیس، یک پنل مدیریت و چند فرم بسازی. یک سیستم مدیریت محتوای جدی یعنی: مدیریت کاربر، نقش‌ها، دسترسی‌ها، امنیت، سشن‌ها، تنظیمات، زبان‌ها، قالب‌ها، افزونه‌ها، فایل‌ها، کش، دیتابیس، مهاجرت، لاگ‌ها، خطاها، نصب و راه‌اندازی، به‌روزرسانی، توسعه‌پذیری و ده‌ها بخش ریز و درشت دیگه که باید کنار هم درست کار کنن. سیستم‌هایی مثل IPB (که برای سال‌ها هم سیستم وب‌سایت خودم iostream بوده) حاصل چند روز و چند ماه نیستن؛ برای ساخت چنین محصولاتی سال‌ها زمان، تجربه، آزمون و خطا، بازطراحی و بلوغ فنی صرف شده. برای همین وقتی از Tegra حرف می‌زنم، منظورم یک CMS ساده یا انجام دهندهٔ یک سری کار‌های تکراری پیش پا افتاده و سطحی نیست که با یه ورد‌پرس هم میشه راه‌اندازیش کرد. تگرا قراره نتیجهٔ سال‌ها نگاه کردن، تحلیل کردن، تجربه کردن و فهمیدن پیچیدگی‌های واقعی چنین سیستم‌هایی باشه؛ اما با یک هدف روشن‌تر: قدرت زیاد در پشت صحنه، سادگی واقعی برای کاربر.

احتمالاً ذهن تکنیکی بعضی‌ها بره به سمت این که چه نیازی هست چند تا موتور بانک اطلاعاتی پشتیبانی بشه همون MySQL کافیه شاید؟! ولی خب یکی از تصمیم‌های مهم در طراحی Tegra CMS اینه که فقط به یک موتور دیتابیس محدود نباشه. دلیلش این نیست که صرفاً بگیم چندتا دیتابیس رو پشتیبانی می‌کنیم؛ دلیلش اینه که برای سال‌ها من با همهٔ این موتور‌ها کار کردم می‌دونم مزایا و معایب و سطح توانایی‌هایی که دارن چیه؛ هدف اینه که کاربر و توسعه‌دهنده با توجه به نوع پروژه، زیرساخت، تجربه قبلی و نیاز واقعی خودش بتونه انتخاب درستی داشته باشه. برای من PostgreSQL انتخاب پیشنهادی و پیش‌فرضه؛ چون برای یک وب‌سایت پیچیده ومدرن، جدی و قابل توسعه، از نظر transaction، integrity، constraintها، indexing، JSONB، پایداری و مقیاس‌پذیری انتخاب بسیار قدرتمندیه به خصوص وقتی ترکیبش کنی با Redis و یا DrogonFly که خوراک شرکت‌ها و سازمان‌های بزرگ محسوب می‌شه. از طرفی در دنیای واقعی، همه روی PostgreSQL نیستن یا از طرفی دلیلی نمی‌بینم که فقط روی MySQL سیستم رو خلاصه کنم! در مورد موتور MariaDB هم باید یک گزینه مستقل دیده بشه، نه فقط یک اسم دیگر برای MySQL. چون در عمل، تفاوت‌هایی وجود داره که در مهاجرت، قابلیت‌ها، رفتار SQL و نگه‌داری بلندمدت خودش رو نشون می‌ده. و اما SQLite هم جای خودش رو داره؛ برای توسعه، تست، دمو، نمونه‌سازی سریع یا پروژه‌های خیلی کوچک یا وب‌سایت‌های بسیار مینیمال. هدف Tegra اینه که CMS فقط روی یک مسیر قفل نشه. کاربر باید موقع نصب بتونه آگاهانه انتخاب کنه: قدرت و پایداری PostgreSQL، سازگاری گسترده MySQL، انعطاف MariaDB، یا سادگی SQLite برای محیط‌های سبک‌تر. هرچند ساختتن درایور‌های مشترک و لایهٔ سوئیچ بسیار سخت بود اما برای من پشتیبانی از چند موتور دیتابیس یعنی آزادی انتخاب، سازگاری با زیرساخت‌های مختلف، جلوگیری از وابستگی اجباری، و ساختن یک CMS که از همان ابتدا برای استفاده واقعی و بلندمدت طراحی شده.

بخش مهمی از این ساختار این هست که تمام ویژگی‌های پیش‌فرض یک سیستم مدیریت وب به واسطهٔ تگرا فراهم میشه. یعنی ساخت و راه‌اندازی یک وب‌سایت، یک بلاگ، یک پایگاه خبری یا یک وب‌سایت خدماتی یا شرکتی یا حتی یک فروشگاه مثل دیجی‌کالا یا حتی فراتر در دنیای وب ۳ مبتنی بر بلاک‌چین. اما موضوع مهم‌تر اینه که زیرساخت این سیستم محدود برای تفکر یک وب‌سایت ساز نیست؛ قابل گسترش و انعطاف‌پذیره برای یک سیستم کاملاً بهینه و آینده‌نگریش هست. پشتیبانی از چند موتور بر مبنای نیاز کاربری مثل Sqlite و همچنین پشتیبانی از MySQL/MariaDB و از همه بهتر PostgreSQL کل داده‌های وب‌سایت رو در ابعادی که مد نظر صاحبین کسب‌و‌کار هست رو پوشش میده. یعنی مثل سیستم‌های کنونی دارای یک نوع دیتابیس نیست! موتور بر مبنای چیزی که نیاز هست قابل انتخابه و این یکی از مواردی هست که خیلی از داده‌کاو‌ها از نظر سیستماتیک بهش اهمیت میدن. البته پشتیبانی زا Redis، Memcache و حتی DragonFly گزینه‌هایی هستن که ساختار مدیریت داده رو با حداکثر بهره‌وری مدیریت خواهد کرد یعنی موضوع بهینگی داده‌ها روی حافظه یکی از ویژگی‌های مهم تگراست و صرفاً از سیستم بانک اطلاعاتی سنتی پشتیبانی نمی‌کنه. هستهٔ اصلی کاملاً با C++23 هست، البته در نسخهٔ آلفا از استاندارد ۱۷ استفاده کرده بودم و با فریم‌ورک Cutelyst که در نسخهٔ بازسازی شده سیستم کاملاً خود کفاست و وابستگی خاصی به فریم‌ورک‌ها یا کتابخانه‌های نوع سوم نداره مگر موارد مهم مانند OpenSSL و Boost برای موضوع مسیر‌یابی آدرس‌ها و برخی از لایه‌های ایمنی. یک نکتهٔ جالب؛ بعید می‌دونم سیستم مدیریت محتوایی پیدا کنید که هم زمان از ساختار بلاک‌چین و وب سنتی پشتیبانی کنه. تگرا این ویژگی رو داره که بدون نیاز به استخدام توسعه‌دهندهٔ بلاک‌چین و صرف هزاران دلار هزینه، خودش سایتی رو برای شما ارائه کنه که از این ساختار پشتیبانی می‌کنه و به شما اجازه میده یک وب‌سایت با قابلیت‌های تطبیق شدن با وب ۳ رو ارائه کنید. البته، یه چیزی که قطعاً مهمه واسم اینه که، GENY سیستم اقتصادی درون برنامه‌ای تگرا خواهد بود علاوه بر اینکه هر نوع درگاه بانکی ایرانی و خارجی رو پشتیبانی خواهد کرد، اما سیستم واحد و یکپارچه‌سازی درون هسته‌ایش توکن جنی خواهد بود. موضوع بعدی از صد‌ها ویژگی دیگه که هنوز نمی‌خوام در موردش صحبتی کرده باشم اینه که تگرا قابلیت پشتیبانی از مهاجرت وب‌سایت‌های کنونی به خصوص ورد‌پرس رو به خودش خواهد داد یعنی شما می‌تونید یک وب‌سایت سنتی رو به یک وب‌سایت مدیرنیزه مطابق بالا‌ترین استاندارد‌ها باز سازی کنید. یعنی اطلاعات وب‌سایت کنونی شما با یک سیستم Migration درون برنامه‌ای قابل انتقال خواهد بود. از ویژگی‌های جالب که از زمان سیستم Eleanor تبعیت می‌کنم، پشتیبانی از چند زبانه بودن سیستمه! یعنی شما به راحتی می‌تونید یک وب‌سایتی رو باهاش بالا بیارید که چند زبان رو به همراه استاندارد‌های قانونی و جغرافیایی و زمانی پشتیبانی کنه. از نظر فنی چندین نکتهٔ جالب داره، یکی از اون‌ها اینه که سیستم در اکثر بخش‌ها به صورت Compile time توسعه یافته! یعنی تا جایی که می‌تونم دارم از ویژگی‌های برجستهٔ استاندارد ۲۳ از سی‌پلاس‌پلاس تبعیت می‌کنم تا موضوع ایمنی و پایداری به حداکثر توان برسه. از نظر گرافیک و طراحی قالب، تگرا قراره از استاندارد‌های کنونی پشتیبانی کنه! چون از Template engine اختصاصی بهره می‌بره و می‌تونه این امکان رو به طراح‌های وب‌سایت بده که قالبی که می‌خوان رو با استاندارد دقیق وب براش باز‌سازی کنن (هرچند ویژگی‌های طراحی بسیار بهتری رو هم خودش ارائه می‌کنه). و یک مورد دیگه و جالب‌تر! تگرا از هوش مصنوعی هم پشتیبانی می‌کنه! این سیستم این قابلیت رو میده که مدیران وب‌سایت به راحتی بتونن تولید محتوا و یا سفارشی‌سازی انجام بدن. البته این بخش هنوز پخته نیست اما چشم‌اندازم نسبت به این ویژگی اینه که در عصر هوش مصنوعی تگرا توجه ویژه‌ای به پشتیبانی از مدل‌های مختلفی از AI خواهد داشت. یک مورد دیگه هم که بسیار بسیار مهمه و خیلی از سیستم‌های مدیریت محتوا حتی نزدیکش هم نیستن، رعایت استاندارد از مصرف انرژی سبز هست. چیزی که ذاتاً PHP یا TS یا JS و هر اسکریپتی که باهاشون سیستم ساختن از همچین انتظاری به دورند. جزئیات و ویژگی‌ها بسیارند اما بماند تا بعد از اولین نسخهٔ قابل آزمایش خودتون خواهید دید.

کسایی که از ۱۵ سال پیش منو می‌شناسن می‌دونن یه زمانی یه CMS روسی رو به فارسی ترجمه کرده بودم، راست به چپش کردم... تمام استاندارد‌های فارسی رو بهش اضافه کردم؛ اسمش بود Eleanor براش قالب طراحی کرده بودم و کلی ماژول و پلاگین اون زمون حسابی جامعهٔ ایرانی در موردش حرف میزد! ولی در نهایت نشد چیزی که می‌خواستم چون سیستم هستش روسی بود و توسعه دهندهٔ اصلیش من نبودم و با سواد ناقص اون موقع نتونستم اونطور که باید پیش ببرمش. در نهایت یه احمق پیدا شد کل چیزی که سفارشی کرده بودم رو عین آب خوردن کپی کرد و با اسم خودشون بالا آورد و بعدشم به خاطر عدم توسعه‌دهندهٔ روسی و بعدش هم پشتیبانی فارسی از طرف من اونم کاسه کوزشو جمع کرد! البته اون موقع گیت‌هاب هم در این حد جا نیفتاده بود، فرهنگ متن باز هم معنای پخته‌ای نداشت. توسعه دهنددهٔ اصلیش هم هم سن من بود ولی کلی تجربه وکلی مهارت در مورد ساختار یک سیستم مدیریت محتوای خوب کسب کردیم. اون موقع زیاد روش تلاش کردم ولی اون دانشی که باید داشتم به قدر کافی نبود که یکی از بیخ بسازم. ولی در نهایت آرزوم بود سیستم مدیریت محتوایی رو که می‌خوام رو از صفر خودم بسازم. تگرا چیزیه که قراره خیلی‌ها رو شگفت‌زده کنه! چیزیه که از تجربهٔ گذشتم و دانش امروزم شکل گرفته! چیزیه که مشتریان وب‌سایت من بارها ازم خواستن و من همیشه گفتم باشه یه روزی می‌سازمش فعلاً با ورد‌پرس حال کنید! یادتون هم باشه ۲ سال پیش یه پیش‌نمایشی از نسخهٔ آلفاش داده بودم در مقایسه با ورد‌پرس! خروجی مصرف منابع صد‌ها برابر بهینه‌تر بود و کلی ویژگی‌های خوب! ولی در نهایت بد شانسی کل هاردم اون موقع سوخت و تمام سورس کد‌هایی که داشتم از بین رفت و تقریباً تا به چند وقت پیش توسعش رو بیخیال شده بودم (احمق بودم به گیت‌هاب اعتقادی نداشتم) و اگرنه زحماتم به باد نمیرفت. اما باز‌سازی تمام ایده‌هایی که داشتم در قالب یک سیستم مدیریت محتوای خوب؛ اهمیت زیادی برای من داره و قراره علاقه‌مندان به CMS رو شگفت‌زده کنه. 😎