وبسایت گیت‌لب (لینک) همچون سایر سرویس‌های مشابه، امکان میزبانی کردن پرونده‌ها و صفحات ایستا را به شما می‌دهد. در این پست، قصد داریم بررسی کنیم که چگونه می‌توان یک صفحه ایستا را در گیت‌لب میزبانی کرد.

ساخت مخزن

پس از ساخت حساب کاربری در گیت‌لب، یک مخزن ایجاد کنید. برای مثال، اگر نام کاربری شما username است، پیشنهاد می‌شود که نام مخزن را username.gitlab.io بگذارید. این مخزن، می‌تواند عمومی یا خصوصی باشد (معمول است که مخازن وبسایت یا وبلاگ شخصی خصوصی ساخته شوند. اما اگر نیاز است که روش ساخت، شیوه‌نامه یا جاوااسکریپت خود را با دیگران شریک شوید، بهتر است مخزن را عمومی کنید).

ساخت پرونده‌های مورد نیاز

پس از این که مخزن ساخته شد، پوشه‌ای روی رایانه خود ایجاد کرده و برای مثال نامش را username.gitlab.io بگذارید. سپس داخل پوشه، پرونده‌ها را به این شکل ایجاد کنید :

username.gitlab.io/
├── .gitlab-ci.yml
└── index.html

توجه کنید که ممکن است پرونده‌های شما بیشتر نیز بشوند، برای مثال پوشه‌ای برای شیوه‌نامه‌ها، پوشه‌ای برای جاوااسکریپت و … ممکن است نیاز داشته باشید. فلذا هرچه کنار index.html نیاز است را درون این پوشه قرار دهید.

ویرایش پرونده gitlab-ci

این پرونده، به شما کمک می‌کند که پرونده‌های ایستای خود را، روی گیت‌لب قرار دهید. به عبارتی، کاری که این پرونده انجام می‌دهد «یکپارچه‌سازی مستمر» یا Continuous Integration است. درون این پرونده، باید مراحل «استقرار» یا Deploy پروژه، تعریف شود. برای این منظور، از YAML استفاده می‌شود.

برای استقرار یک صفحه ایستا، تنها کافیست به این شکل، این پرونده را ویرایش کنید :

pages:
 stage: deploy
 scirpt:
  - mkdir .public
  - cp -r * .public
  - mv .public public
 artifacts:
  paths:
   - public
 only:
  - master

در قسمت اول، می‌گوییم که قرار است روی Gitlab pages چیزی ساخته شود. در قسمت stage مشخص می‌کنیم که قرار است پرونده‌های تولید شده، کجا قرار بگیرند.

در قسمت script ابتدا یک پوشه مخفی می‌سازیم و سپس تمام محتوا را به آن منتقل می‌کنیم. علت مخفی بودن این پوشه، این است که دستور cp تلاشی برای کپی کردن خود پوشه نکند.

پس از آن، این پوشه را از حالت مخفی خارج کرده و سپس، در قسمت artifacts مشخص می‌کنیم که مسیر مورد نظر؛ پوشه public است. پس از انجام تمام مراحل کافی است که در بخش only مشخص نماییم فقط از شاخه master پرونده‌ها را خوانده و به پوشه public منتقل کند.

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

بسیاری از افراد، از «تولیدکنندگان صفحات ایستا» یا Static Generator ها استفاده می‌نمایند. استفاده از این ابزارها، بسیار سریع و به صرفه بوده و معمول است که جای درگیر شدن با طراحی ایستا، از این‌ها استفاده شود. شما می‌توانید از تولیدکنندگان صفحات ایستا مانند jekyll یا hugo روی گیت‌لب استفاده نمایید. در آموزش بعدی، بررسی می‌کنیم که چگونه می‌توان یک بلاگ با جکیل روی گیت‌لب ایجاد و مدیریت کرد.

مدتی پیش، خواستم یک نمونه شخصی از ماستودون بسازم. موقع نصب، ارورهای عجیب و غریب دریافت کردم و خب شروع کردم به جست و جو پیرامون این که چرا اینطوریه و خیلی‌ها واضحا بیان کردند که «مشکل از تصویر داکر PostgresSQL بوده و باید روی اون تصویر کمی تغییر داده شه».

حقیقتا من از PGSQL استفاده نکردم و خیلی هم دلم نمیخواست وارد قضیه بشم و روی داکرفایل و داکر کامپوز و …، تغییر ایجاد کنم. به نظرم همون چیزی که خود توسعه‌دهنده پیشنهاد می‌کنه، معمولا بهترین حالتیه که داره با نرم‌افزار کار می‌کنه. اما یه ایده‌ای به سرم زد و اون هم این بود که چی میشه اگر پشتیبانی از MySQL رو به این بزرگوار اضافه کنم؟ نتیجه این شد که تصمیم گرفتم این مطلب رو بنویسم 😀

ماستودون چیه؟

ماستودون یک شبکه اجتماعی از نوع «فدریتد» (انگلیسی : Federated) محسوب میشه. به این شکل که وقتی شما روی سرور خودتون هم اون رو اجرا کنید، می‌تونید باقی سرورها رو ببینید و تعامل کنید.

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

نگاه به کد و چندکلمه‌ای صحبت پیرامون اون

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

در نگاه اول، کد واقعا ایراد خاصی (جز ایرادات مرسوم پروژه‌های مشابه) رو نداره. اما اولین ایراد جایی خودش رو نشون میده که شما چندین کتابخونه سیستمی اضافی نیاز دارید. برای من libicu و libidn و اینا بود. یکم جا خوردم که چرا باید این‌ها نصب باشه؟ اما با کمی تحقیق در موردش، فهمیدم که یک سری از کتابخونه‌های روبی هستند که وابسته به این بزرگوارهان. در واقع، هردوی این‌ها به شکلی برای پردازش متن استفاده شدند و خب این که پردازش متن، از طرف سیستم انجام بشه خیلی منطقیه. این موضوع فقط کمی باعث بزرگتر شدن پروژه شده. اما خوبی‌هاش، به شدت بیشتر از بدی‌هاشه.

مورد بعدی اروری بود که سر PGSQL گرفتم. خب حقیقتا انتظار این یکی رو داشتم. چون PGSQL و کتابخونه‌های سیستمیش، روی سیستم من نصب نیستند (البته شاید بعدها مجبور شم برای اشکال زدایی و کمک به همین ماستودون، نصبش کنم) و خب اروری که گرفتم دقیقا همین رو می‌گفت. وقتی مطمئن شدم که هیچ کتابخونه دیگری مشکلی نداره، دست به کار شدم که PGSQL رو با MySQL عوض کنم.

پروسه تغییر سیستم مدیریت پایگاه داده

خب معمولش اینه که اول، به پروژه می‌گیم کتابخونه‌های لازم رو نصب کنه. نیاز بود روی سیستم libmysqlclient-dev هم نصب کنم و کردم. بعدش در Gemfile، جم‌های مربوط به مدیریت MySQL رو اضافه کردم و جم‌های مربوط به PGSQL رو به دیدگاه تبدیل کردم و رفتم سراغ مراحل ساخت پروژه.

متاسفانه، اینجا کلی ارور گرفتم سر یک سری جم خاص! جم‌هایی که مرتبط با PGSQL هستند و شدیدا Hard Code شدن رو در کد منبع، شاهد بودیم.

قسمتیش رو دستی حذف کردم به امید این که کار کنه. اما موقع اجرای Migration ها، ارورهای جدیدی گرفتم. قسمت بزرگی از Migration ها رو چک کردم و دیدم که یه جاهایی حتی به صورت دستی دستورات PGSQL نوشته شده. حس می‌کردم که دیگه از اینجا جلوتر رفتن، یه جورایی مسخره کردن خودم باشه. حقیقتا بود، چون اصلا آشنا نبودم به این که اینجا چه اتفاقی داره می‌افته و خب بیخیال اضافه کردن پشتیبانی MySQL به این پروژه شدم.

جمع‌بندی

همونطوری که عرض کردم خدمت شما، بزرگترین اشکال این کد اینه که شدیدا وابسته به PGSQL عه. اگر اینقدر هاردکد نمی‌شد، شاید وضعیت طور دیگری بود و می‌شد پشتیبانی پایگاه‌های دیگر رو بهش اضافه کرد. متاسفانه در issue هایی که در پروژه بود هم دیدم که خیلی صریح پیشنهادات مرتبط با MySQL رو رد کردند و امیدم رو به طور کلی به این پروژه برای اضافه کردن این دیتابیس، از دست دادم.

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

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