Changes in the structure

[fzerorubigd]

holiday

سلام فرود جان؛ اول از همه دستت درد نکنه، از ایده‌ات واقعا خوشم اومد و این کار، پروژه جالب و مفیدی می‌تونه بشه.

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

راستش دیروز و امروز یه چیزی‌هایی رو تست کردم که در تسریع روند واردسازی اطلاعات تاثیر می‌ذاره و فکر کنم باعث بشه مشارکت عمومی برای این پروژه راحت‌تر و بدون خطا‌تر بشه؛ در حقیقت یه بک‌اند + فرانت‌اند ساده و جمع‌وجور که عمومی همه بتونن از طریق اون در تکمیل اطلاعات مشارکت کنن.

بخش بک‌اند با netlifycms همچین چیزی میشه برای این استارکچر

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

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

لایو اینجاست

بخش ادمین هم از اینجا میشه دید. خوبی این کار اینه که میشه editorial workflow رو راحت‌تر مدیریت کرد.

Originally posted by @kevinmiston in #11 (comment)

[okian]

.دقیقا بهش فکر کرده بودم ولی به نظرم الان زود باشه @kevinmiston

[fzerorubigd]

بحث خیلی مهم اینه که خروجی بدون تغییر باقی بمونه. یعنی پوشه dist البته اونم نه همه فایلهاش. ما میخوایم در نهایت برای هر تقویم یه فایل داشته باشیم که این فایل خروجی این رپوزیتوریه و درنهایت ما اون رو به عنوان محصول کار میذاریم تو بخش ریلیز. ساختاری که اونجا به وجود میاد چون قراره که دیگران ازش استفاده کنن غیر قابل تغییره. (البته ما هنوز ورژن اولیه رو ندادیم و هنوز میتونیم بحث کنیم درباره اون و تغییرش بدیم، بعد ریلیز اول به شدت سعی خواهیم کرد backward compatible باشیم و چیزی رو حذف نکنیم، اضافه کردن هم با احتیاط انجام بدیم )

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

برای ویرایش ایده من این بود که یه وب سرور کوچیک بنویسم با گو با دقیقا یه همچین UI ساده ای. هر کی تو لوکال خودش میتونه رانش کنه و بعد این کار رو کاملا لوکال انجام بده و نتیجه رو پوش کنه. منتها چون خیلی وقته هیچ کار فرانتی انجام ندادم داشتم از زیرش در میرفتم :))))

در مورد هوگو، اگه این PR رو ببینی #43 میخواستم که فایل هوگو رو تو پس اول جنریت کنم، تو یه پوشه موقتی وقت تست، و بعد نتیجه کامپایل هوگو رو (در حقیقت تو پس دوم) منتقل کنم به فولدر dist و بعد پوش کنم به برنچ gh-pages
ولی اینکه فایلهای سورس ازاول هوگو باشن، به نظرم درست نیست. چون هدف اصلی درست کردن یه time.ir دیگه حالا استاتیک نیست، هدف اصلی ایجاد فایل json/yaml و فرمتهای دیگه برای استفاده برنامه‌نویسهایی مثل خودمه که بتونن تو برنامه‌شون استفاده کنن.

[okian]

اگر قرار شد انجامش بدیم باید یک پروژه مجزا بشه با دیتا‌بیس خودش که ورودی‌های جدید رو بگیره و پس از ریویو .مثلا یک بات به این پروژه پول‌ریکوست بزنه اینطوری کسانی که برنامه‌نویسی هم نمیدونند میتونند مشارکت کنند

[fzerorubigd]

در مورد هوگو ما میتونیم همینجا اینکار رو بکنیم. یعنی، فایلهای yaml مربوط به هر ماه رو بگیریم، فایل ورودی هوگو رو ایجاد کنیم، هوگو رو روی فایلهای ایجاد شده ران کنیم، یه سری فایل html درست میشن که توی مستر کامیت نمیشن، بلکه میرن مستقیم تو برنچ gh-pages و اینجا هم در نهایت یه وبسایت خواهد داشت. فایلهای json/yaml ایجاد شده هم میرن همونجا برای دانلود.

به نظر من زیاد پیچیده نمیاد. فقط باید یک نمونه ماه رو اول دستی درست کنیم تا ببینیم خروجی اون generator چجوری باشه

[exotita]

بحث خیلی مهم اینه که خروجی بدون تغییر باقی بمونه. یعنی پوشه dist البته اونم نه همه فایلهاش. ما میخوایم در نهایت برای هر تقویم یه فایل داشته باشیم که این فایل خروجی این رپوزیتوریه و درنهایت ما اون رو به عنوان محصول کار میذاریم تو بخش ریلیز. ساخت...

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

در مورد تفکیک به یک فایل برای رویداد، من بهش فکر کردم. ولی نگهداری همچین چیزی به نظرم عجیب غریب اومد. هدف این نیست که اینو درست کنیم و بعد ولش کنیم به امون خدا :) ولی ترجیح شخصی من این بود که یه مقدار مشخصی رو بسپریم به یه نفر برای مینتین. مثلا من ...

خوبی جدا بودن هر رویداد به‌صورت یک فایل مستقل اینه که حتی میشه برای هر مورد، به‌صورت مستقل issue و decision داشت. من راستش به بحث پیش‌روی کار به‌لحاظ صحت و اعتبار محتوا + زمانی فکر می‌کنم که مثلا یک رویدادی توی contribute‌ها اضافه میشه (حالا چه توی تقویم جلالی فعلی و چه حتی به تقویمی که مناسبت‌های جزئی‌تر داره) که اونجا پیگیری این مساله که آیا رویداد رسمی هست یا نه؛ یا مثلا قابل قبول از نظر عموم هست که به مجموعه اضافه بشه یا و... چنین چیزهایی.

جدای این، تفکیک شدنش، توی مدیریت دیتاها با netlifycms خیلی راحت‌تر میشه. حالا یه نمونه تست دیگه درست می‌کنم که بهتر بررسی بشه.

برای ویرایش ایده من این بود که یه وب سرور کوچیک بنویسم با گو با دقیقا یه همچین UI ساده ای. هر کی تو لوکال خودش میتونه رانش کنه و بعد این کار رو کاملا لوکال انجام بده و نتیجه رو پوش کنه. منتها چون خیلی وقته هیچ کار فرانتی انجام ندادم داشتم از زیرش در میرفتم :))))

این netlifycms رو روی سرویس Netlify‌ هر کسی می‌تونه ران کنه و خوبیش اینه که رایگانه و خوشبتاخته فعلا ایران رو تحریم نکرده

در مورد هوگو، اگه این PR رو ببینی #43 میخواستم که فایل هوگو رو تو پس اول جنریت کنم، تو یه پوشه موقتی وقت تست، و بعد نتیجه کامپایل هوگو رو (در حقیقت تو پس دوم) منتقل کنم به فولدر dist و بعد پوش کنم به برنچ gh-pages
ولی اینکه فایلهای سورس ازاول هوگو باشن، به نظرم درست نیست. چون هدف اصلی درست کردن یه time.ir دیگه حالا استاتیک نیست، هدف اصلی ایجاد فایل json/yaml و فرمتهای دیگه برای استفاده برنامه‌نویسهایی مثل خودمه که بتونن تو برنامه‌شون استفاده کنن.

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

[exotita]

اگر قرار شد انجامش بدیم باید یک پروژه مجزا بشه با دیتا‌بیس خودش که ورودی‌های جدید رو بگیره و پس از ریویو .مثلا یک بات به این پروژه پول‌ریکوست بزنه اینطوری کسانی که برنامه‌نویسی هم نمیدونند میتونند مشارکت کنند

@okian قابلیت editorial workflow کمک می‌کنه که این مساله برای ریویو مدیریت بشه.

چنین چیزی میشه که در نهایت اینجا تایید میشن که مرج بشن یا نه، عملا کاری که بات می‌خواد انجام بده، جدای این
validate کردن اطلاعات واردسازی شده، خیلی راحت‌تره

[fzerorubigd]

برای تفکیک روز به روز، یه چیزی که به نظرم میرسه رویدادهای چند روزه هستن. برای رویدادهای چند روزه، -مثل عید نوروز- هدفم این بود که یه کلید درست بشه برای همشون. منتها اگه به فرض یه رویدادی اینجوری باشه که چهار روز باشه و هر روزش یه اسم داشته باشه یکم مشکل میشه.
البته در فایل نهایی تولید شده این یک رویداد تبدیل میشه به چند رویداد. اگه در مورد رویدادهای چند روزه تصمیم بگیریم، من مشکلی برای تفکیک به رویداد نمیبینم.

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

در مورد اینکه فعلا ایران رو تحریم نکردن، من یکم شکاک شدم نسبت به قضیه. نمیدونم وابستگی به یه سرویس خارجی که هر لحظه ممکنه ما رو فیلتر کنه درسته یا نه.

[fzerorubigd]

در مورد هوگو فکر کنم مشکلی نیست همین الان شروع کنیم،‌یه ایشو میزنم و جداگاه اونجا حرف میزنیم. در مورد ویرایشگر هنوز جای بحث هست.

[exotita]

در مورد اینکه فعلا ایران رو تحریم نکردن، من یکم شکاک شدم نسبت به قضیه. نمیدونم وابستگی به یه سرویس خارجی که هر لحظه ممکنه ما رو فیلتر کنه درسته یا نه.

وابستگی نداره، کل قضیه میشه سلف هاست یا هر جای دیگه که فایل استاتیک میزبانی میکنه برای سایت، امکان پشتیبانیشو داره؛ کل دیتاها هم براساس گیت در هر جایی مدیریت میشه. من هم موقت برای اینکه تست انجام بدیم ازش استفاده می‌کنم.

[fzerorubigd]

من آشنایی ندارم کلا باهاش. بنابراین نظری ندم بهتره :) کسی اگه میدونه چیه و مشکلی داره با قضیه، اینجا مطرح کنه.