---
title: آفتابه لگن هفت دست
tags: وب جکیل بیهنه‌سازی
uuid: 0f7dd450-d612-4a44-b489-3d018a157e2b
---
در تعطیلات سال نو فرصتی و همتی فراهم شد که نگاه دوباره‌ای به سایت‌ساز وبسایتم داشته باشم. تغییرات گسترده‌ای ایجاد کردم که در ادامه شرح می‌دهم.

قصدم در ابتدا نوشتن مقاله‌ای درباره‌ی یک پروژه‌ی کوچک چندین ساله بود و قصد داشتم از نوشتن مقاله‌ی دیگری در مورد وبسایت پرهیز کنم. ولی چند سال کم‌کاری باعث شده بود که تا حدود زیادی فراموش کنم که اصلا چطور سایتم را می‌سازم و اجزاء آن چگونه کار می‌کنند. وقتی دقیق‌تر به سورس نگاه کردم به عمق فاجعه پی بردم. بنابراین چاره‌ای جز پنج روز کار بی‌وقفه روی وبسایت باقی نمانده بود.

خاطرتان باشد در گذشته مقاله‌ای نوشته بودم بنام [گزارش تغییرات اساسی در پیش رو](upcoming-changes.html). به جرأت می‌توانم بگویم مهمترین یادداشتی است که در این وبسایت منتشر کرده‌ام و از اسفند ۹۹ سرلوحه‌ی کارم بوده است. وقتی با آن نگاه و البته تجربه‌ی سالهای گذشته به نحوه‌ی ساخت این سایت تقریبا[^۱] استاتیک نگاه کردم مشکلات زیر نظرم را جلب کرد:

- تعداد زیادی افزونه‌ی ریز و درشت
- تعداد زیادی فایل با روابط فی‌مابین پنهان از دید برنامه‌ساز
- تعداد زیادی فایل SASS برای قالب‌ها به شکلی در هم ریخته
- عدم امکان دیباگ فرم کامنت‌دونی (سرور وب داخلی جکیل فقط فایل سرو می‌کند)
- مارک‌آپ تکراری (یکپارچکی را از میان می‌برد چرا که صفحات شبیه هستند اما نه کاملا)
- مخلوط پایتون و روبی
- عدم استفاده از متغیرهای  CSS (زمانی که وبسایت را ساختم هنوز وجود نداشتند)
- نداشتن قالب متغیر تیره و روشن (شب‌ها قالب تیره برای مطالعه برای چشم‌هایم راحت‌تر است)
- کدهای مرده
- برچسب‌های فراوان و همچنین ترکیب برچسب و سرفصل با نام یکسان

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

لازم است توضیح بدهم که قوانین متعدد CSS و تکثر فایل‌های بکاررفته در قالب‌بندی و همچنین تکثر زبان‌های برنامه‌نویسی (روبی و پایتون) و نبود دسترسی مستقیم به افزونه‌ها، که هر تغییر را منوط به تغییر یک پروژه‌های خارجی می‌کند، از مهمترین مشکلات بودند چرا که فهم آنچه در پروژه می‌گذرد را سخت می‌کردند. مثلا من افزونه‌ای نوشته بودم به نام jekyll-hinduarabic و برای آن هم مخزن جداگانه‌ای ساخته بودم و آن را رویRubyGems منتشر کرده بودم. تنها کاری که می‌کرد تبدیل اعداد لاتین به اعداد فارسی بود. آن همه قیل و قال برای هیچ. آن را آوردم داخل پروژه و تبدیل کردمش به یک پلاگین ساده‌ی روبی که با یک کلیک در دسترس است و امکان تغییرش وجود دارد. آن مخزن را هم آرشیو کردم.

بعد همینکار را با افزونه‌ی سایت‌مپ کردم. این افزونه اصلا به روبی احتیاج نداشت. تبدیل شد به یک فایل ساده‌ی sitemap.xml با مقداری کد قالب Liquid و افزونه حذف شد.

بعد رفتم سروقت تقویم جلالی و افزونه‌ی جکیلی که برای آن نوشته بودم. الگوریتم تبدیل تاریخ میلادی به شمسی را به کمک هوش مصنوعی نوشتم و مطالعه و کد تولیدی را اصلاح کردم و به افزونه‌های روبی اضافه کردم. افزونه‌ی تبدیل اعداد و فیلترهای قالب را هم درونش ادغام کردم. فورا هم با خطی یا به اصطلاح اینلاین شدن این افزونه‌ی خارجی تغییراتی برای رفع نیاز وبسایتم در آن انجام دادم. مثلا یک فیلتر اضافه کردم که خروجی‌اش مقداری کد HTML است که به تاریخ جلالی تولیدی به کمک المان‌های وب ساختار می‌دهد (به کمک time و همچنین روز و ماه و سال را جدا می‌کند که بتوان استیلش را تغییر داد) و همچنین تاریخ میلادی را در عنوان اضافه می‌کند (اگر با ماوس روی تاریخ‌ها بروید تاریخ میلادی نمایش داده می‌شود - یک هک کوچک سودمند).

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

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

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

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

افزونه‌ی دیگری بود برای تولید جدول مطالب که فقط یکجا استفاده کردم که آنرا هم به کمک هوش مصنوعی کلاود آوردم داخل پروژه و تغییر دادم تا عناوین داخلی هر پست را هم به لینک‌های داخلی تبدیل کند (تا بشود بدون سرفصل مطالب هم به یک زیرعنوان مسقیما لینک داد).

یک افزونه‌ی دیگر هم برای سئو بود که داخل هدرهای سایت مرج کردم و او هم به ابدیت ملحق شد. یکی دیگر هم برای ساخت لینک صفحات قبلی و بعدی بود که در گذشته مثل جگر زلیخا مقداری‌اش داخل پلاگین بود و مقداری هم پراکنده داخل سایت (بسیاری افزونه‌ها مقداری هم کد Liquid لازم دارند چون فقط داده را فراهم می‌کنند و مانند اینها). آن را هم به کمک هوش مصنوعی دوباره نوشتم و اصلاح کردم تا فقط نیازهای سایت را برآورده کند. 

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

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

تمام این پلاگین‌ها حذف یا جذب شدند:
```ruby
group :jekyll_plugins do
  gem "jekyll-paginate"
  gem "jekyll-sitemap"
  gem "jekyll-jalali"
  gem "jekyll-hinduarabic"
  gem "jekyll-tagging-lite"
  gem "jekyll-tagging-related_posts", :git => "https://github.com/mehdisadeghi/jekyll-tagging-related_posts", :ref => "a58844c"
  gem "liquid_reading_time"
  gem "jekyll-seo-tag"
  gem "jekyll-include-cache"
  gem "jekyll-toc"
end
```

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

مقایسه‌ی تعداد فایل‌های CSS قدیم و جدید:
```bash
$ ls src/_sass/ old/src/_sass/
../mdx/src/_sass/:
_base.scss	_fonts.scss   _print.scss     _vars.scss
_comments.scss	_layout.scss  _pygments.scss
_dark.scss	_post.scss    _tagcloud.scss

src/_sass/:
base.scss  layout.scss	pygments.scss
```

مقایسه‌ی تعداد فایل‌های قالب قدیم و جدید:
```bash
$ ls src/_layouts/ old/src/_layouts/
old/src/_layouts/:
bare.html	     feed_per_post.xml	message.html  post.html
category_index.html  headless.html	minimal.html  project.html
default.html	     home.html		page.html     tag_page.html

src/_layouts/:
atom.liquid  comments_feed.liquid  post.liquid	   tag.liquid
base.liquid  list.liquid	   project.liquid
```

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

این روش باعث شد که تعریف رنگ‌ها ساده‌تر بشود. تمام رنگ‌های دیگر را به کمک متغیرها و امکانات امروزی وب بر اساس این رنگ مبداء تعریف کرده‌ام. هیچ رنگی جز یک رنگ در سایت تعریف نشده است. حسن اینکار اینست که براحتی می‌توان رنگ‌ها را تغییر داد حتی هنگامی که سایت ساخته شده است. برای اینکار یک هک کوچک در سایت قرار داده‌ام. کافیست کلید بک‌تیک را فشار بدهید (‍`). باید یک نوار افقی بالای پست‌ها ظاهر شود که اجازه می‌دهد این رنگ اصلی را تغییر بدهید و مشاهده کنید چطور تمام رنگ‌ها نسبت به آن تغییر می‌کنند.

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

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

بخشی از اسریپت‌های پراکنده را هم به Rakefile پروژه منتقل کردم که معادل Makefile است منتها برای پروژه‌های روبی. ابتدا قصدم حذف کامل Makefile بود ولی متاسفانه به جهت کم‌سوادی محقق نشد حالا هر دو را داریم! دستوراتی هم اضافه کردم که ساخت مقاله‌ی جدید یا مقاله‌ی ناتمام را ساده کنند.

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

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

امیدوارم که این قصه‌ی ساده‌سازی تشویقت کند پروژه‌هایت را ساده کنی.

[^۱]: ثبت دیدگاه به یک سرور احتیاج دارد.