سیستم‌های انتشار شخصی

پروژه تکرارشونده هیچ‌وقت فقط «ساختن یک وب‌سایت» نبود.

بیشتر شبیه این بود:

ساختن یک سیستم انتشار شخصی که بعد از قدیمی شدن اولین طراحی هم هنوز مفید بماند.

طراحی زود قدیمی می‌شود. هوم‌پیج بعد از مدتی دیگر حس درست نمی‌دهد. فریم‌ورک عوض می‌شود. CMS آزاردهنده می‌شود. دامنه معنای تازه‌ای پیدا می‌کند. پورتفولیو دیگر شبیه آدم پشت خودش نیست.

اما نیاز باقی می‌ماند.

جایی برای نوشتن. جایی برای نگه‌داشتن یادداشت‌ها. جایی برای منتشر کردن کارها. جایی برای مستند کردن پروژه‌ها قبل از اینکه تبدیل به case studyهای مرتب شوند. جایی که ایده‌های قدیمی فقط به‌خاطر عوض شدن interface از بین نروند.

این رشته پشت چند repository مختلف دیده می‌شود:

• mohetios/totoro

• mohetios/front

• mohetios/front_old

• mohetios/Inbox

• mohetios/mohetios.dev

این‌ها یک پروژه واحد نیستند، اما به یک الگوی مشترک تعلق دارند.

هرکدام تلاشی بوده‌اند برای جواب دادن به یک سؤال آرام:

یک آدم فنی چطور باید حافظه عمومی کارهایش را نگه دارد؟

وب‌سایت به‌تنهایی کافی نبود

یک سایت شخصی معمولاً با هویت شروع می‌شود.

من کی هستم؟ چه کاری انجام می‌دهم؟ چطور می‌شود با من تماس گرفت؟ کدام پروژه‌ها را باید نشان بدهم؟

این‌ها مفیدند، اما کافی نیستند.

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

نه فقط نسخه صیقلی آدم را، بلکه حرکت را:

• تجربه‌های قدیمی

• یادداشت‌های فنی

• تحقیق‌های نیمه‌تمام

• تصمیم‌های پروژه

• مسیرهای بن‌بست

• migrationها

• ابزارهای کوچک

• draftهای عمومی

• تمرکز فعلی

• مسیر تماس

• آرشیو نوشته‌ها

• کارهایی که هنوز اسم دقیق ندارند

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

پورتفولیو چیزی را نشان می‌دهد که آماده است.

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

این تفاوت برای Mohetios مهم است.

Mohetios.dev فقط جایی برای نمایش کارهای تمام‌شده نیست. جایی است که ایده‌ها، یادداشت‌ها، تجربه‌ها، و سیستم‌های محصولی می‌توانند آرام‌آرام به نرم‌افزارهای قابل استفاده تبدیل شوند.

الگوی صفحه‌های شخصی قدیمی

front pageهای قدیمی بیشتر سطح هویتی بودند.

تلاشی برای ساختن یک خانه عمومی: جایی برای نام، پروژه‌ها، لینک‌ها، تجربه‌ها، و یک شخصیت فنی.

این نوع سایت فشار آشنایی دارد.

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

اما بعد از نسخه اول، فشار واقعی عوض می‌شود.

سؤال این می‌شود:

آیا این سایت می‌تواند رشد کند؟

آیا می‌تواند یادداشت نگه دارد؟ آیا می‌تواند پروژه نگه دارد؟ آیا می‌تواند نوشته نگه دارد؟ آیا می‌تواند تجربه‌های قدیمی را نگه دارد، بدون اینکه شبیه وعده محصول فعلی دیده شوند؟ آیا می‌تواند تغییر کند، بدون اینکه آرشیوش را از دست بدهد؟

اینجاست که front page تبدیل به مسئله publishing می‌شود.

یک سایت شخصی خوب نمی‌تواند فقط landing page بماند. به مدل آرشیو نیاز دارد.

Totoro: Jamstack مبتنی بر Git به‌عنوان سطح نوشتن

Totoro قدم مهمی بود، چون سایت را به‌عنوان یک سطح انتشار Jamstack می‌دید.

استک آن Nuxt، Decap CMS، Cloudflare Pages، static generation، و محتوای Git-backed بود.

بخش مهم فقط تکنولوژی نبود.

بخش مهم قرارداد بود:

محتوا باید نزدیک repository زندگی کند.

این قرارداد اهمیت دارد.

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

انتشار Git-backed این رابطه را عوض می‌کند.

محتوا هنوز فایل است. تاریخچه هنوز قابل دیدن است. سایت را می‌شود دوباره ساخت. CMS را می‌شود حذف کرد. renderer را می‌شود عوض کرد. آرشیو زنده می‌ماند.

Decap CMS مفید بود، چون یک UI تحریریه‌ای روی Git می‌داد. نوشتن را راحت‌تر می‌کرد، بدون اینکه محتوا را از repository جدا کند.

برای خیلی از سیستم‌های انتشار شخصی، این شکل درستی است:

یک لایه ویرایش دوستانه، اما نه زندان محتوا.

Front Old: سایت شخصی به‌عنوان ظرف تجربه‌ها

پروژه آرشیوشده front_old شاخه دیگری از همین فکر را نشان می‌دهد.

فقط یک front page شخصی نبود. تجربه‌هایی حول Jamstack، Nuxt، WebRTC، GUNDB، Web3، ایده‌های NFT marketplace، Cloudflare Pages، و مفهوم‌های P2P network را هم با خودش حمل می‌کرد.

از بیرون شاید این ترکیب کمی شلوغ به نظر برسد، اما یک چیز مفید می‌گوید.

سایت شخصی خیلی وقت‌ها همان جایی است که تجربه‌های ظاهراً نامرتبط برای اولین بار به هم برخورد می‌کنند.

انتشار. هویت. ایده‌های P2P. مالکیت محتوا. تجربه‌های Web3. رابط‌های real-time. workflowهای CMS. معماری فرانت‌اند.

این‌ها همه یک محصول نیستند، اما می‌توانند در یک فاز کارگاهی کنار هم زندگی کنند.

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

درس این است که یک سیستم انتشار شخصی باید بتواند stateهای مختلف کار را از هم جدا کند.

پروژه فعلی نباید شبیه prototype قدیمی دیده شود.

lab note نباید شبیه محصول کامل دیده شود.

research fragment نباید شبیه سرویس آماده برای مشتری دیده شود.

تجربه retired باید هنوز خواندنی باشد، بدون اینکه وانمود کند active است.

این تبدیل شد به یکی از قانون‌های طراحی Mohetios:

نوع‌های محتوا را جدا کن، چون شکل‌های مختلف کار به شکل‌های مختلف پیر می‌شوند.

مدل محتوا مهم است

یک bucket کافی نیست.

اگر همه چیز فقط «post» باشد، سایت مبهم می‌شود.

tutorial مثل lab note نیست. project page مثل case study نیست. about page مثل manifesto نیست. technical article مثل changelog نیست. contact page مثل product surface نیست. تجربه نیمه‌تمام مثل سرویس active نیست.

Mohetios به content typeهای جدا نیاز دارد، چون سایت مسئولیت‌های جدا دارد.

Blog برای نوشته‌های بلند، مقاله‌های فنی، tutorialها و یادداشت‌های تحلیلی است.

Lab برای تجربه‌ها، prototypeها، سیستم‌های ناتمام، fragmentهای تحقیقاتی، و باستان‌شناسی پروژه‌هاست.

Projects برای کارهای public-facing است که به شکل روشن‌تر، context، لینک repository، لینک demo، و status فعلی نیاز دارند.

Pages برای هویت پایدار و وعده‌های سطح سایت است: about، contact، شاید now و principles.

Tags تزئین نیستند. لایه حافظه‌اند. کمک می‌کنند یادداشت‌های قدیمی دوباره به‌عنوان بخشی از یک thread بزرگ‌تر دیده شوند.

این مدل ساده است، اما سایت را از تبدیل شدن به توده‌ای از فایل‌های markdown حفظ می‌کند.

سیستم محتوا فقط نباید prose را render کند.

باید رابطه بین قطعه‌های کار را توضیح بدهد.

Mohetios.dev: کارگاه فعلی

Mohetios.dev نسخه فعلی این سیستم انتشار طولانی‌مدت است.

بیشتر از یک پورتفولیو است.

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

بخش عمومی این‌ها را نگه می‌دارد:

• نوشته‌های blog

• lab noteها

• project writeupها

• صفحه‌های about و contact

• tagها

• newsletter signup

• commentهای moderated

• هویت فنی

بخش خصوصی این‌ها را نگه می‌دارد:

• inbox

• leads

• comment moderation

• newsletter subscribers

• analytics

• notifications

• workflowهای owner

این ترکیب مهم است.

یک سیستم انتشار شخصی فقط درباره render کردن markdown نیست. باید اتفاقات بعد از انتشار را هم مدیریت کند.

آدم‌ها می‌خوانند. آدم‌ها جواب می‌دهند. آدم‌ها تماس می‌گیرند. آدم‌ها comment می‌گذارند. آدم‌ها subscribe می‌کنند. آدم‌ها فرصت کاری می‌فرستند. آدم‌ها سؤال می‌پرسند.

پس سایت هم انتشار است، هم دریافت.

برای همین inbox مهم است.

سایت شخصی بدون سیستم تماس، یک تابلوی static است.

سایت شخصی با یک inbox کوچک و owned، تبدیل می‌شود به یک سطح کاری واقعی.

از CMS به Pipeline

سیستم محتوای فعلی Mohetios از لایه CMS سنتی فاصله گرفته و به سمت build-time content pipeline رفته است.

ایده ساده است:

Markdown بنویس، اعتبارسنجی کن، تبدیل کن، و از طریق سایت render کن.

Velite با این مسیر می‌خواند، چون محتوا را مثل typed data می‌بیند. Markdown و frontmatter فایل‌های loose نیستند که UI در runtime اتفاقی کشف کند. source recordهایی هستند که از build pipeline رد می‌شوند.

این چند مزیت می‌دهد:

• schema محتوا explicit می‌شود

• frontmatter خراب زودتر fail می‌شود

• data تولیدشده typed است

• table of contents و syntax highlighting می‌تواند قبل از runtime آماده شود

• صفحه‌های عمومی می‌توانند prerender شوند

• frontend به‌جای parse کردن raw Markdown در هر request، compiled content می‌خواند

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

نوشتن همچنان file-based و portable می‌ماند.

اپ همچنان یک content layer ساختاریافته می‌گیرد.

build step تبدیل می‌شود به ویراستار بین prose و interface.

Git لایه حافظه است

Git ابزار نوشتن بی‌نقصی نیست.

به راحتی یک editor اختصاصی نیست. گاهی noisy است. برای code ساخته شده، نه essay. خودبه‌خود نوشته را بهتر نمی‌کند.

اما برای یک سیستم انتشار فنی، Git یک مزیت عمیق دارد:

تغییر را به خاطر می‌سپارد.

این برای کار شخصی مهم است.

یک یادداشت می‌تواند خام شروع شود و روشن‌تر شود. یک پروژه قدیمی می‌تواند تبدیل به case study شود. یک lab fragment می‌تواند به project page منتقل شود. یک draft می‌تواند مقاله عمومی شود. نسخه فارسی می‌تواند بعد از نسخه انگلیسی بیاید. یک ایده فنی می‌تواند ماه‌ها بعد ویرایش شود، بدون اینکه تاریخچه‌اش از بین برود.

Git باعث می‌شود نوشتن کمتر شبیه upload نهایی باشد و بیشتر شبیه record کاری.

برای Mohetios، این مدل درست است.

سایت فقط نباید فکرهای تمام‌شده را منتشر کند. باید اجازه بدهد فکرها بالغ شوند.

انتشار دوزبانه فقط ترجمه نیست

Mohetios دوزبانه است: انگلیسی و فارسی.

این فقط یک feature برای localization نیست.

سیستم انتشار را عوض می‌کند.

انگلیسی و فارسی لازم نیست ساختار جمله یکسان داشته باشند. بعضی ایده‌ها باید مستقیم ترجمه شوند. بعضی باید بازنویسی شوند. بعضی در انگلیسی باید فنی‌تر باشند و در فارسی انسانی‌تر. بعضی باید ساختار مشابه داشته باشند، چون آرشیو به parity نیاز دارد.

یک سایت شخصی دوزبانه باید به هر دو احترام بگذارد.

labelهای UI می‌توانند در فایل‌های i18n زندگی کنند. prose باید مثل prose زندگی کند. نسخه فارسی باید اجازه داشته باشد فارسی به نظر برسد. نسخه انگلیسی باید اجازه داشته باشد در انگلیسی طبیعی باشد. دو نسخه باید به هم وصل باشند، اما نباید به تقارن ماشینی مجبور شوند.

این برای Mohetios مهم‌تر است، چون بخشی از سایت حرفه‌ای است، بخشی شخصی است، و بخشی فلسفی.

سیستم باید translation را پشتیبانی کند، اما نوشته‌ها نباید بوی ترجمه بدهند.

مسئله هوم‌پیج

هوم‌پیج سخت است، چون می‌خواهد همه چیز شود.

پورتفولیو. رزومه. فهرست بلاگ. داشبورد. feed. صفحه محصول. manifesto شخصی. مسیر تماس.

اگر بخواهد همه این‌ها را هم‌زمان و برابر انجام دهد، ضعیف می‌شود.

هوم‌پیج یک سیستم انتشار شخصی باید به چند سؤال کوچک‌تر جواب بدهد:

اینجا چه جایی است؟ الان چه چیزی فعال است؟ چه چیزی می‌توانم بخوانم؟ این آدم چه چیزهایی ساخته؟ از کجا عمیق‌تر بروم؟ چطور تماس بگیرم؟

باید حرکت را نشان بدهد، بدون اینکه تبدیل به dashboard شود.

این تعادلی است که برای Mohetios می‌خواهم.

هوم‌پیج باید زنده باشد، اما آرام.

تمرکز فعلی، نوشته‌های تازه، lab noteهای انتخاب‌شده، و پروژه‌های عمومی را نشان بدهد. نباید هر metric، هر admin action، یا هر فکر ناتمام را بیرون بریزد.

داشبورد جای خودش را پشت owner surface دارد.

هوم‌پیج متعلق به خواننده‌هاست.

آرشیو مهم‌تر از Feed

Feed برای تازگی مفید است.

Archive برای حافظه مفید است.

یک سیستم انتشار شخصی به هر دو نیاز دارد، اما در طول زمان archive مهم‌تر می‌شود.

Feed می‌گوید: چه چیزی تازه است؟

Archive می‌گوید: این آدم چند سال است درباره چه چیزهایی فکر می‌کند؟

Mohetios نباید تبدیل به social feed شود. باید تبدیل به آرشیو ساختاریافته کار شود.

یعنی محتوای قدیمی نیاز به مراقبت دارد:

• URLهای پایدار

• تاریخ روشن

• تاریخ update

• status label

• tagها

• لینک پروژه

• لینک repository

• related notes

• نسخه‌های زبانی

• migration note

• context صادقانه وقتی ایده قدیمی تغییر کرده

برای همین lab noteها مهم‌اند.

اجازه می‌دهند کار قدیمی قابل دیدن بماند، بدون اینکه وانمود کند final است.

Status بخشی از محتواست

سیستم انتشار نباید فقط title، date و body ذخیره کند.

باید وضعیت کار را هم نگه دارد.

چند status مفید:

• Active

• Refining

• Exploring

• Archived

• Paused

• Shipped

• Deprecated

Status بروکراسی نیست. جهت‌دهی به خواننده است.

اگر کسی یک note قدیمی را باز کند، باید بفهمد با فکر فعلی روبه‌روست، context تاریخی، تجربه ناتمام، یا ایده retired.

این برای کار فنی خیلی مهم است.

یک پیاده‌سازی ۲۰۱۹ ممکن است هنوز pattern مفیدی یاد بدهد، اما نماینده stack فعلی نباشد.

یک تجربه P2P در ۲۰۲۱ ممکن است هنوز product thinking خوبی نشان بدهد، اما محصول maintained نباشد.

یک مقاله Mohetios در ۲۰۲۶ ممکن است معماری فعلی را نشان بدهد.

Status به سایت صداقت می‌دهد.

نوشتن به‌عنوان زیرساخت

مهم‌ترین تغییر این است:

نوشتن زیرساخت است.

نه مارکتینگ. نه تزئین. نه کاری بعد از کار اصلی.

نوشتن باعث می‌شود پروژه قابل فهم شود.

پروژه فنی بدون نوشتن سخت قابل اعتماد است. تجربه قدیمی بدون note سخت قابل بازیابی است. سیستم بدون tradeoff سخت قابل ارزیابی است. پورتفولیو بدون context سخت در ذهن می‌ماند. هویت عمومی بدون نوشته خیلی راحت تخت و ساده‌سازی می‌شود.

Mohetios برعکس این فکر ساخته شده است.

context را بنویس. تصمیم‌ها را بنویس. tradeoffها را بنویس. مسیرهای شکست‌خورده را بنویس. بنویس چه چیزی تغییر کرد. بنویس قدم بعدی چیست.

لایه نوشتاری، سیستم را durable می‌کند.

قانون‌های طراحی برای سیستم فعلی

مسیر فعلی را می‌شود به چند قانون کم کرد.

۱. محتوا را نزدیک Git نگه دار

repository باید source of truth برای محتوای بلند بماند.

ابزارهای ویرایش می‌توانند workflow را بهتر کنند، اما نباید آرشیو را زندانی کنند.

۲. content typeها را جدا نگه دار

Blog، Lab، Projects، Pages و Tags باید جدا بمانند، چون هرکدام جور دیگری پیر می‌شوند.

۳. انتشار را boring کن

مسیر commit تا deploy باید قابل پیش‌بینی باشد.

یک سیستم انتشار شخصی نباید هر بار برای انتشار از آدم انرژی عصبی بگیرد.

۴. prose را portable نگه دار

Markdown کامل نیست، اما به‌اندازه کافی durable است.

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

۵. بگذار کار قدیمی دیده شود

تجربه‌های قدیمی نباید فقط چون دیگر current نیستند حذف شوند.

باید label بخورند، context بگیرند، و به فکرهای جدیدتر وصل شوند.

۶. سایت را مثل کارگاه ببین

سایت باید هم کار تمام‌شده و هم کار ناتمام را نگه دارد، بدون اینکه این دو را با هم اشتباه بگیرد.

۷. سطح owner را جدا نگه دار

خواننده عمومی clarity می‌خواهد.

owner عملیات می‌خواهد: inbox، leads، comments، subscribers، analytics، notifications.

این‌ها باید همدیگر را پشتیبانی کنند، اما نباید یک interface شوند.

۸. به دو زبان با احترام بنویس

فارسی نباید بوی ترجمه ماشینی انگلیسی بدهد.

انگلیسی نباید precision را از دست بدهد.

هر دو باید متعلق به یک کارگاه باشند.

قدم بعدی

نسخه بعدی این سیستم باید کمتر دنبال redesign و بیشتر دنبال کیفیت انتشار باشد.

هسته اصلی هست.

حالا کار این است که آرشیو قوی‌تر شود:

• محتوای قدیمی با دقت migrate شود

• تاریخچه پروژه‌ها نوشته شود

• related-note linkها اضافه شود

• status labelهای Lab بهتر شود

• پروژه‌ها به مقاله‌ها وصل شوند

• دیاگرام‌های معماری اضافه شود

• نسخه‌های فارسی و انگلیسی طبیعی بمانند

• writing loop از Obsidian یا یک editor مبتنی بر Git راحت شود

• pipeline محتوای Mohetios مستند شود

• تجربه‌های قدیمی front page به‌عنوان بخشی از داستان عمومی حفظ شوند

هدف این نیست که مدام سایت را از نو بسازیم.

هدف این است که سایت آن‌قدر قوی شود که کارهای آینده بتوانند داخلش جمع شوند.

یک سیستم انتشار شخصی خوب باید از redesignها جان سالم به در ببرد.

باید از تغییر frameworkها جان سالم به در ببرد.

باید از تغییر هویت حرفه‌ای جان سالم به در ببرد.

باید کار را بعد از رفتن اولین interface هم خواندنی نگه دارد.

سؤال‌های باز

هنوز سؤال‌های مفیدی باقی مانده:

• کدام محتوای front pageهای قدیمی باید وارد Mohetios شود؟

• کدام repositoryهای قدیمی باید lab note شوند و کدام‌ها فقط آرام آرشیو بمانند؟

• project pageها باید دستی نوشته شوند، از metadata repository ساخته شوند، یا هر دو؟

• related noteها چطور باید بین blog، lab و project وصل شوند؟

• آیا سایت باید draft preview از content branchها داشته باشد؟

• Obsidian دقیقاً کجای writing workflow بنشیند؟

• آیا dashboard بعداً باید content review queue داشته باشد؟

• چقدر metadata کافی است قبل از اینکه فرایند نوشتن سنگین شود؟

• محتوای قدیمی چطور باید context تاریخی داشته باشد، بدون اینکه کهنه و بی‌ارزش حس شود؟

• چه چیزی باید public writing باشد و چه چیزی فقط private note بماند؟

این‌ها فقط سؤال‌های content management نیستند.

سؤال‌هایی‌اند درباره اینکه یک آدم چطور حافظه عمومی کارهایش را نگه می‌دارد.

چک‌لیست کار

• مدل Decap CMS در Totoro را با pipeline فعلی Velite مقایسه کن.

• یک دیاگرام کوتاه برای publishing flow در Mohetios.dev اضافه کن.

• تصمیم بگیر front، front_old و Inbox کجای داستان عمومی قرار می‌گیرند.

• برای انتقال محتوای قدیمی به ساختار فعلی content/en و content/fa migration note بنویس.

• تعریف statusها را برای Lab و Project مشخص کن.

• related-note linkها را بین blog، lab و project اضافه کن.

• برای repositoryهای قدیمی content migration checklist بساز.

• frontmatter schema پایدار برای blog، lab، projects و pages تعریف کن.

• writing workflow سازگار با Obsidian اضافه کن که همچنان Git را source of truth نگه دارد.

• مسیر انتشار از فایل Markdown تا صفحه deployشده را مستند کن.

• تجربه‌های قدیمی سایت شخصی را بررسی کن و به archive، lab یا project history برچسب بزن.

پروژه تکرارشونده ساختن یک وب‌سایت دیگر نیست.

ساختن یک سیستم انتشار پایدار برای حافظه فنی است.

Mohetios.dev نسخه فعلی همین سیستم است:

یک کارگاه Git-backed که در آن نوشته‌ها، پروژه‌ها، تجربه‌ها، یادداشت‌ها و هویت عمومی می‌توانند بدون از دست دادن تاریخچه‌شان به شکل‌گرفتن ادامه بدهند.