🛴 🚪 ➕ गोब्लॉग: गो ब्लॉगिंग के लिए होममेड स्टेटिक इंजन 🤽🏻 🤶 👩🏻‍🚒

मुझे ग्रंथ लिखना पसंद है, मुझे उदाहरणों पर बहस करना, कोशिश करना, विश्लेषण करना पसंद है। मुझे जो पसंद नहीं है वह प्रारूपण, चित्रों को अपलोड करने, लेआउट की जांच करने आदि के साथ खिलवाड़ है।

आलस्य के कारण मैंने Blogspot का उपयोग करना शुरू कर दिया। यहां आप और टेम्पलेट का समुद्र, सभी प्रकार के विजेट, Google द्वारा त्वरित अनुक्रमण, आंकड़े अलग-अलग हैं, क्योंकि कुछ समय बाद भी टिप्पणियां पेड़ की तरह, और अन्य सीटी बन गई हैं। ठीक है, सब कुछ ठीक हो जाएगा, लेकिन, अफसोस, Blogspot संपादक प्रोग्रामर पोस्ट बनाने के लिए अभिप्रेत नहीं है। जब आपको कोड एम्बेड करने की आवश्यकता होती है या टेबल अलग होते हैं, तो पीड़ा शुरू होती है। उदाहरण के लिए, मेरे अन्य ब्लॉग के लिए, प्रोग्रामिंग के बारे में नहीं, मुलायम उबले अंडे, सर! , "अवसर" Blogspot पर्याप्त है।

मैं मूल पोस्ट को सामान्य रूप से नहीं, नग्न रूप में रखना चाहता हूं। यह पता चला कि ब्लॉग सामग्री यहां और वहां कई प्रतियों में बिखरी हुई थी। पहले आप केवल संपादक में पाठ लिखते हैं, केवल लिंक और चित्रों के बिना पैराग्राफ में इसे तोड़ते हैं, और अंत में आप लगभग समाप्त दस्तावेज़ को बचाते हैं। तब HTML टाइपिंग शुरू होती है, जिसके दौरान, HTML के अलावा, मूल पाठ में सुधार किए जाते हैं। उसी समय, मूल फ़ाइल को अपडेट करना पहले से ही बहुत आलसी है, और वास्तव में, यह "कच्चे" रूप में रहता है। और "ड्राई" फॉर्म में, केवल HTML कचरा रहता है। लेकिन यह कहानी का अंत नहीं है। अक्सर प्रकाशन के बाद, आप एक टाइपो नोटिस करते हैं, ब्लॉगस्पॉट में चढ़ते हैं और पृष्ठ पर दाईं ओर संपादित करते हैं। फिर से, बहुत पहले मूल और इसके स्थानीय ओब-एचटीएमएल संस्करण अपरिवर्तित रहते हैं। अंत में: पदों का वर्तमान संस्करण केवल ब्लॉगस्पॉट पर ही है। बेशक, आप पूरे ब्लॉग का एक स्वचालित बैकअप बना सकते हैं, लेकिन फिर से - सब कुछ केवल HTML में होगा।

कुछ समय पहले मैंने ReST का उपयोग करना शुरू किया। यहां, किसी तरह जीवन बेहतर महसूस हुआ। ReST आपको अधिक या कम पूर्वानुमेय मार्कअप (पैराग्राफ, लिंक, कोड) में पाठ लिखने की अनुमति देता है, और फिर HTML इससे उत्पन्न होता है, जिसे ब्लॉगस्पॉट में (फिर से मैन्युअल) डाला जाता है। Googlecl के माध्यम से पोस्ट के पूर्वावलोकन को स्वचालित करने के प्रयास वास्तव में विफल रहे हैं। फिर से, समस्या तब बनी रही, जब पृष्ठ पर एक टाइपो को सही करने के बाद, ReST में मूल दस्तावेज पुराना हो गया था। इसके अलावा, ReST ने चित्र समस्या को हल नहीं किया। उन्हें पहले से कहीं बाहर रखा जाना था, ताकि आप पूरी तरह से पूर्वावलोकन कर सकें।

मैं समझा नहीं सकता कि क्यों, लेकिन वर्डप्रेस जैसे गतिशील इंजनों के विचार ने मुझे किसी तरह डरा दिया। डेटाबेस में पोस्ट रखने का बहुत विचार मुझे ओवरकिल लगता है।

मैं लगभग पहले से ही एक मध्यवर्ती समाधान - डोकू विकी पर , उदाहरण के लिए, vak.ru पर बसे। यहां, हालांकि इंजन गतिशील है, पृष्ठों की सामग्री फ़ाइलों में संग्रहीत है, और वहाँ संस्करण है। डोकू को केवल ब्लॉग ही नहीं बल्कि पूरी साइट के इंजन के रूप में इस्तेमाल किया जा सकता है। हालांकि डिज़ाइन बदसूरत है, लेकिन सिस्टम द्वारा चित्रों और मनमाने संलग्नकों का समर्थन किया जाता है।

एक और विकल्प था, जिसे मैंने लगभग सदस्यता भी दे दी थी - एक ब्लॉग जो टिडलीविकी पर आधारित था। TiddlyWiki मेरा पसंदीदा विंडोज रिकॉर्डिंग टूल है। मैंने इस बारे में पहले ही लिख दिया था । केवल विंडोज पर ही क्यों? क्योंकि मैक पर, मैं सिर्फ साधारण पाठ फ़ाइलों में नोट्स बनाता हूं, उन्हें दस्तावेजों या डेस्कटॉप पर अर्थ में रखता हूं, और स्पॉटलाइट , जो कंप्यूटर पर सब कुछ और सब कुछ अनुक्रमित करता है, तुरंत आपको शब्दों के टुकड़ों की खोज करने की अनुमति देता है। यह पता चला है कि TiddlyWiki की प्रमुख विशेषताएं - तत्काल खोज, अब कोई मतलब नहीं है। लेकिन मैं विचलित था।

पता चला कि ऐसे प्रशंसक हैं जो TiddlyWiki को ब्लॉगिंग प्लेटफॉर्म में बदल गए। एक प्रकार के स्थैतिक-गतिशील उत्परिवर्ती में।

उदाहरण के लिए, इस तरह के इंजन के साथ एक ब्लॉग विकल्प रिच सिग्नल का वर्क लॉग है । मेरी राय में गूढ़। उदाहरण के लिए, यह स्पष्ट नहीं है कि टिप्पणियों को कैसे तेज किया जाए, कम से कम एक ही डिस्कस। लेकिन अगर किसी को दिलचस्पी है, तो सार्वजनिक होस्टिंग भी है - tiddlyspot ।

और वास्तव में, मैं विशुद्ध रूप से स्थिर इंजन के विचार के बारे में उत्साहित हो गया। यहां की खूबसूरती यह है कि आप इस तरह के ब्लॉग को कहीं भी होस्ट कर सकते हैं। यहां, न केवल डेटाबेस की आवश्यकता है, बल्कि सर्वर-साइड स्क्रिप्टिंग भी है। लेकिन आगे - और। गिटहब या हरोकू आपको न केवल स्थिर साइटों की मेजबानी करने की अनुमति देता है, बल्कि गिट के माध्यम से सामग्री का प्रबंधन भी करता है।

उदाहरण के लिए, एक स्थिर जेकेल इंजन है। जेकिल में, मार्कडाउन या टेक्सटाइल मार्कअप का उपयोग करके पोस्ट लिखे जाते हैं। आप प्रोजेक्ट में मनमानी फाइलें भी जोड़ सकते हैं, जो कि साइट बनाते समय, बिना किसी बदलाव के रखी जाएगी। वास्तव में, यह एक साइट इंजन है जहां आप अभी भी कुछ फ़ाइलों को एक ब्लॉग के रूप में डिज़ाइन कर सकते हैं।

टिप्पणियाँ, ब्लॉग के मुख्य "गतिकी" के रूप में, उदाहरण के लिए, डिस्कस के माध्यम से कार्यान्वित की जा सकती हैं। वैसे, ज़ेन की उच्चतम डिग्री के साथ स्थिर ब्लॉगों के एस्थेट हैं - स्थिर टिप्पणियों के साथ (मेरे लिए, यहां तक कि यह वाक्यांश एक ऑक्सीमोरोन है)। यहां दृष्टिकोण इस प्रकार है: नीचे दिए गए पोस्ट में एक अनुभाग है जो सांख्यिकीय रूप से पहले दर्ज की गई टिप्पणियों से प्रदर्शित होता है, और इसके बगल में एक नया दर्ज करने के लिए एक रूप है। आप एक टिप्पणी दर्ज करते हैं और इसे ब्लॉग के लेखक को भेजा जाता है। वह इसकी पुष्टि करता है (या नहीं), कहीं पर क्लिक करता है, और टिप्पणी को स्थिर ब्लॉग परियोजना में एक फ़ाइल के रूप में रखा जाता है, सब कुछ फिर से इकट्ठा किया जाता है और जनता के सामने रखा जाता है। यह स्पष्ट है कि यह कभी वास्तविक समय नहीं है, लेकिन पूर्व-मॉडरेशन के साथ टिप्पणियों की तरह अधिक है, और मध्यस्थ सप्ताह में एक बार संपर्क में आता है।

मैं वास्तव में चर्चा की सराहना करता हूं, और यह दृष्टिकोण मेरे लिए नहीं है। और मैं Disqus का उपयोग जारी रखता हूं। वैसे, डिस्कस से आप टिप्पणी डेटाबेस को पूरी तरह से निर्यात कर सकते हैं, और, उदाहरण के लिए, इसे स्थैतिक पृष्ठों में बदल दें यदि आपको अचानक इसे छोड़ना पड़ता है।

लेकिन वापस Jekyll के लिए। उदाहरण के लिए, GitHub Pages सीधे Jekyll का समर्थन करता है (इसका लेखक GitHub का सह-संस्थापक है) और Jekyll प्रोजेक्ट्स को रेंडर कर सकता है (हालांकि आप इसे स्थानीय रूप से खुद को रेंडर कर सकते हैं)। आप git के माध्यम से Jekyll प्रोजेक्ट को भरते हैं, और साइट GitHub Pages में दिखाई देती है।

हरोकू में, विचार थोड़ा अलग है। हरोकू रूबी को होस्ट करता है, इसलिए हरोकू पर स्थिर साइट खुद पेज और वेब सर्वर प्रोग्राम है जो उन्हें दूर करता है। यह डरावना लगता है, लेकिन रूबी पर ऐसा सर्वर बहुत कॉम्पैक्ट दिखता है, उदाहरण के लिए:

require 'bundler/setup' require 'sinatra/base' class SinatraStaticServer < Sinatra::Base get(/.+/) do send_sinatra_file(request.path) {404} end def send_sinatra_file(path, &missing_file_block) file_path = File.join(File.dirname(__FILE__), 'public', path) file_path = File.join(file_path, 'index.html') unless file_path =~ /\.[az]+$/i File.exist?(file_path) ? send_file(file_path) : missing_file_block.call end end run SinatraStaticServer

अजीब तरह से, हरोकू पर होस्टिंग आमतौर पर गीथहब की तुलना में सरल है। इसके अलावा, हेरोकू पर, ब्लॉग गिट रिपॉजिटरी निजी बनी हुई है, जबकि गिटहब पर यह अन्य सभी परियोजनाओं की तरह खुला है। हालाँकि मुझे ब्लॉग प्रोजेक्ट (वास्तव में, साइट) को बंद रखना अजीब लगता है। वह पहले से ही वेब के माध्यम से पूरी तरह से सुलभ है।

हां, GitHub Pages और Heroku दोनों आपको एक सामान्य द्वितीय-स्तर डोमेन "पेंच" करने की अनुमति देते हैं, यदि आपके पास एक है।

इसलिए, मैंने हरोकू पर होस्टिंग के साथ जेकेल को चुना। काश, यदि आप शुद्ध जेकेल लेते हैं, तो आपको शैलियों और पृष्ठ लेआउट को खरोंच से खुद को डिजाइन करना होगा। यदि यह आलस्य द्वारा किया जाता है, तो आप ऑक्टोप्रेस ले सकते हैं।

ऑक्टोप्रेस Jekyll पर आधारित एक स्थिर ब्लॉग इंजन है, लेकिन जो सुंदर एचटीएमएल 5 पेज लेआउट, आसान प्लग-इन का एक गुच्छा और गिटहब पेज और हरोकू पर एक ब्लॉग पोस्ट करने की स्वचालित क्षमता से लैस है।

इसलिए, मैंने ऑक्टोप्रेस लिया, इसे आगे और पीछे घुमाया, कई पदों की कोशिश की, स्थानीय स्तर पर ब्लॉग रेंडरिंग का परीक्षण किया, इसे हरोकू और गिटहब पेज पर अपलोड किया। सब कुछ मरहम पर लग रहा था।

अगला Marlezon बैले का सबसे थकाऊ हिस्सा था - अपने पसंदीदा Blogspot से पोस्ट खींचें और छोड़ें। वास्तव में, मुझे इसे मैन्युअल रूप से कट-एंड-पेस्ट के माध्यम से करना था। तीन सप्ताह की पीड़ा, और मेरे दुखी तीन सौ पद मैंने संसाधित किए।

मेरा नया स्थिर ब्लॉग लॉन्च करने के लिए सब कुछ तैयार था। लेकिन यहां मुख्य निराशा ने मेरा इंतजार किया। रूबी में लिखा गया अनमोल जेकेल, मेरे दुखी तीन सौ पदों (ध्यान!) - 15 मिनट (मैक एयर पर) का प्रतिपादन किया। और जैसा कि आप समझते हैं, पहले आपको बहुत प्रयास करना था, फिर से इकट्ठा करना, फिर से प्रयास करना, फिर से इकट्ठा करना, आदि। और इस तरह के पूर्ण विश्राम का समय किसी भी गेट पर नहीं चढ़ता था।

पोक विधि का उपयोग करते हुए, मुझे Jekyll / Octopress इंजन में एक अड़चन मिली - इन 15 मिनट के शेर का हिस्सा atom.xml फ़ाइल, RSS फ़ीड बनाने में चला गया। किसी कारण से, मूल टेम्पलेट्स में, इस आरएसएस फ़ाइल में केवल अंतिम बीस पोस्ट शामिल थे। लेकिन मेरे पास एक छोटा सा ब्लॉग है, इसलिए मैंने वहां सभी पोस्टों को शामिल किया, और फिर इस फाइल के पीढ़ी समय ने पूरे ब्लॉग के पंद्रह मिनट का निर्माण किया।

यह सब मुझे किसी तरह बेतुका लगा (रूबी के लिए मेरे सारे प्यार के साथ)। थोड़ा विचार करने के बाद (उस समय तक मैं पहले से ही Jekyll internals को कम या ज्यादा समझ गया था) और इसे तेज करने के प्रयास में Jekyll को रखने की अनिच्छा, मुझे आश्चर्य हुआ कि क्या मुझे भी इसी तरह के विचार पर अपना स्वयं का स्थिर इंजन लिखना चाहिए? आखिरकार, यह सिर्फ फाइलों, पाठ और संभवतः टेम्प्लेट के साथ काम करता है। इसके अलावा, जेकिल में किसी भी रूप में कोई बहुभाषिकता नहीं है, और मुझे इसे वहां जोड़ने की योजना थी, लेकिन अपने स्वयं के इंजन के साथ मेरे हाथ पूरी तरह से अछूते हैं, और सब कुछ सामंजस्यपूर्ण और खूबसूरती से किया जा सकता है।

किस पर लिखना है? यह मर्दाना संभव है: सी ++ / बूस्ट पर। यह बहुत तेजी से काम करेगा, लेकिन उबाऊ। मैंने गो पर फैसला किया। मूल, बहुत तेज़ संकलन (वास्तव में, मेरे पास संकलन चरण नहीं है, क्योंकि यह प्रारंभ चरण के साथ संयुक्त है), तार के साथ सुविधाजनक काम और फ़ाइल सिस्टम, मेमोरी (कचरा कलेक्टर) के साथ सरलीकृत काम, नियमित अभिव्यक्ति, सरणियाँ, हैश, टेम्पलेट्स का एक पुस्तकालय। मार्कडाउन के लिए पुस्तकालय । अंतिम को छोड़कर सब कुछ बॉक्स से बाहर है। प्रदर्शन की कोई समस्या नहीं होनी चाहिए। यहां गो 1 का विमोचन हाल ही में हुआ, और अब विंडोज और मैक के लिए सामान्य वितरण हैं।

इसलिए, तीन शाम के बाद, मेरी बाइक का जन्म हुआ - गोब्लॉग । पूरा प्रोजेक्ट खुला है। साइट और इसके स्रोत एक साथ हैं।

कार्य सिद्धांत

दो मुख्य स्थान हैं: परियोजना और इकट्ठे ब्लॉग साइट। पहली स्रोत फ़ाइलें है। विधानसभा प्रक्रिया के दौरान, परियोजना से फाइलें स्थानीय निर्देशिका संरचना को बनाए रखते हुए इकट्ठे साइट पर कॉपी की जाती हैं। डिफ़ॉल्ट रूप से, फ़ाइलों को बाइनरी की तरह अपरिवर्तित कॉपी किया जाता है। यदि किसी भी फाइल में एक्सटेंशन html , xml या js , तो यह फाइल गो टेम्पलेट सिस्टम के माध्यम से चलाई जाती है । मार्कडाउन लाइब्रेरी द्वारा markdown एक्सटेंशन के साथ फाइल markdown आगे टेम्प्लेट से पहले प्रोसेस किया जाता है।

कैटलॉग:

<root> यहां असेंबल की गई साइट है, जैसा कि http://demin.ws/ पर देखा जाता है।
<root>/_engine - यह एक प्रोजेक्ट है, यहाँ स्रोत और साइट जनरेटर हैं। तकनीकी रूप से, यह निर्देशिका वेब के माध्यम से भी दिखाई देती है।

उप-निर्देशिकाएँ और फाइलें _engine निर्देशिका में:

_includes - वे फाइलें जिन्हें मैक्रो {{include "filename"}} माध्यम से प्रतिस्थापित किया जा सकता है।
_layouts - _layouts फ़ाइलें (नीचे देखें)।
_site - वास्तव में, निर्देशिका और साइट फ़ाइलें। यह निर्देशिका भविष्य की साइट का मूल है। असेंबली के दौरान इससे फ़ाइलें असेंबल साइट पर स्थानांतरित की जाती हैं। कुछ टेम्पलेट्स द्वारा नियंत्रित किया जाता है।
_posts - पदों के स्रोत। इन फ़ाइलों को विशेष रूप से संसाधित किया जाता है। टेम्प्लेट के अलावा, उनका नाम ब्लॉग की संरचना के अनुसार बदल दिया जाता है, जहाँ दिनांक URL का भाग होता है: " /blog/////-/ "

पोस्ट एक विशेष शीर्षक और नाम के साथ मार्कडाउन फाइलें हैं। इन फ़ाइलों को दिनांक उपनिर्देशिकाओं के साथ एक अलग /blog निर्देशिका में रखा गया है। पदों के बारे में जानकारी विशेष चर में एकत्र की जाती है जो टेम्प्लेट से दिखाई देते हैं। इसके अलावा, खोज के लिए एक रिवर्स इंडेक्स पदों पर बनाया गया है।

लेआउट

लेआउट के विचार Jekyll से विरासत में मिले हैं। यदि पोस्ट या पेज में हेडर में एक layout विशेषता है ( उदाहरण के लिए ), तो निर्दिष्ट लेआउट टेम्पलेट ( _layouts निर्देशिका से) इसे रेंडर करने के लिए लोड किया जाता है, पोस्ट या पेज का शरीर एक विशिष्ट लेआउट स्थान में डाला जाता है (मेरे पास यह पेज। बच्चों के Page.child ), और फिर सब कुछ एक साथ प्रस्तुत किया जाता है। यह आपको समान पृष्ठों (उदाहरण के लिए, पोस्ट) के समूहों को समान रूप से व्यवस्थित करने की अनुमति देता है। लेआउट को नेस्टेड किया जा सकता है।

जनक

और अब, वास्तव में, जनरेटर मुख्य है ।

सभी मैं ( _engine निर्देशिका में) बनाने के लिए है:

 make

निम्नलिखित प्रदर्शित किया जाता है:

 _engine$ make gofmt -w=true -tabs=false -tabwidth=2 main.go go run main.go Go static blog generator Copyright (C) 2012 by Alexander Demin Words in russian index: 18452 Words in english index: 3563 15.672979s Processed 344 posts.

यदि सब कुछ ठीक है, तो प्रोजेक्ट रूट (में .. _engine सापेक्ष) फाइलें बनती हैं जो गणना के लिए तैयार हैं। मेरे मैक एयर पर, असेंबली में 15 सेकंड (हैलो, जेकेल / ऑक्टोप्रेस और अलविदा) लगते हैं। चूंकि सब कुछ गिट के अधीन है, आप हमेशा स्पष्ट रूप से देख सकते हैं कि कहां और कौन सी फाइलें दिखाई दीं, गायब हो गईं या बदल गईं।

फिर आप साइट को स्थानीय रूप से देख सकते हैं (नीचे देखें)।

यदि सब कुछ तैयार है, तो आप स्थानीय रिपॉजिटरी में संशोधित फाइलें ( _site/ से स्रोत और एकत्रित फ़ाइलें दोनों) जोड़ सकते हैं:

git add ../*
git प्रतिबद्ध -m "नई पोस्ट के बारे में ..."

और इसे GitHub पेजों पर डालें:

जोर का धक्का

लगभग push देने के तुरंत बाद push फाइलें डिमिनट पर दिखाई देती हैं ।

Makefile में जीवन को आसान बनाने के लिए कुछ अतिरिक्त कमांड हैं।

स्थानीय परीक्षण

साइट को स्थानीय रूप से शुरू करने के लिए, मैं अस्थायी रूप से " 127.0.0.1 demin.ws " को /etc/hosts 127.0.0.1 demin.ws और मिनी वेब सर्वर शुरू /etc/hosts 127.0.0.1 demin.ws । याद है कि यह रूबी में कैसा दिखता था? छोटा, सही? और अब Go ( server.go ) पर संस्करण:

 package main import "net/http" func main() { panic(http.ListenAndServe(":80", http.FileServer(http.Dir("..")))) }

तो:

 go run server.go

और आप स्थानीय रूप से साइट का परीक्षण कर सकते हैं (आपको पोर्ट 80 पर "बैठ जाओ" के लिए sudo से गुजरना पड़ सकता है)।

सिद्धांत रूप में, आप localhost:80 पते को /etc/hosts स्पर्श या उपयोग नहीं कर सकते हैं, लेकिन atom.xml RSS फ़ीड में डोमेन के साथ पूर्ण लिंक होते हैं, इसलिए यदि आपको RSS का परीक्षण करने की आवश्यकता है, तो आप बिना स्पूफ किए ऐसा नहीं कर सकते।

सिंटेक्स हाइलाइटिंग

मार्कडाउन एक्सटेंशन के रूप में, मेरे पास कोड के ब्लॉक डालने के लिए एक विशेष टैग है:

 {% codeblock lang:xxx %} ... {% endcodeblock %}

मुझे यह टैग ऑक्टोप्रेस से विरासत में मिला है। मार्कडाउन में पहले से ही कोड के लिए सिंटैक्स है:

 ``` xxx ... ```

जहां xxx भाषा है।

लेकिन मेरा टैग मेरे लिए विशेषताओं को जोड़ना आसान बनाता है, उदाहरण के लिए, पंक्ति संख्याओं के प्रदर्शन को सक्षम करना, टैब को परिवर्तित करना, आदि।

अगला, सिंटैक्स हाइलाइटिंग के मुद्दे को हल करना आवश्यक था। मैंने पृष्ठ पर सीधे जावास्क्रिप्ट के माध्यम से रंग भरने वाले कई ऑनलाइन पुस्तकालयों को घुमाया, लेकिन प्रत्येक में कुछ न्यूनतम समस्या थी, इसलिए मैंने कोड को सांख्यिकीय रूप से रंग देने का फैसला किया।

पहली बात जो दिमाग में आई वह थी पाइनेस । सब कुछ ठीक होगा, लेकिन पायथन के लिए धन्यवाद, यह बहुत धीरे-धीरे काम करता है। साइट की असेंबली को 15 सेकंड से पूरा करने का समय बढ़कर दो मिनट हो गया। अधिकांश समय कोड को रंग देने में व्यतीत होता था। पहले से पेंट किए गए टुकड़ों और अन्य बकवास के कैश के बारे में विचार आया था, लेकिन एक छोटी खोज के बाद समस्या को मौलिक रूप से हल किया गया था।

आपको बस कार्य के लिए सही भाषा में लिखा गया एक colorizer लेना था। दो विकल्प पाए गए: स्रोत-हाइलाइट और हाइलाइट । दोनों सी ++ में लिखे गए हैं, इसलिए वे लगभग तुरंत काम करते हैं।

उदाहरण के लिए, यहां एक आदमी ने पाइनेस और सिंटैक्स-हाइलाइट के प्रदर्शन की तुलना की ।

मुझे हाईलाइट ज्यादा पसंद आया। इसमें अधिक भाषाओं का समर्थन किया गया है (उदाहरण के लिए, जीएनयू में भी गो नहीं है)। हाइलाइट पर स्विच करने के बाद, पूर्ण असेंबली का समय ~ 15-16 सेकंड में लौट आया, और मैं संतुष्ट था।

रंगकर्मी को एक कॉलबैक के माध्यम से एक नियमित अभिव्यक्ति में बुलाया गया था जो {% codeblock %} टैग ( हाइलाइट () फ़ंक्शन) को संसाधित करता है।

मार्कडाउन के लिए संपादक

मार्कडाउन के पूर्वावलोकन के साथ संपादकों से भरा हुआ। मैं विंडोज पर मार्कडपैड का उपयोग करता हूं, और मैक पर चिह्नित करता हूं।

टैग (श्रेणियां) पोस्ट

मैंने तय किया कि मैं बिल्कुल भी टैग नहीं करूंगा। अपने स्वयं के अनुभव के आधार पर, मैंने महसूस किया कि मैं कभी भी अपने ब्लॉग पर या अजनबियों पर टैग का उपयोग नहीं करता। इसके अलावा, समय के साथ, सूचनाओं को वर्गीकृत करने के तर्क पर विचार बदल जाते हैं, और कभी-कभी आपको सिर्फ ऐसे टैग लगाने पड़ते हैं जिनमें आप अतीत के साथ संगतता के लिए बिंदु नहीं देखते हैं। उदाहरण के लिए, मेरे ब्लॉग पर c++ टैग में बिंदु क्या है? क्या किसी ने कभी इसका इस्तेमाल किया है?

लेकिन अतिसूक्ष्मवाद जीवन को जटिल बनाने का एक तरीका नहीं है। इसके विपरीत। व्यक्तिगत रूप से, मैं लगातार अपने ब्लॉग पर पुरानी पोस्टों में कुछ ढूंढ रहा हूं। ब्लॉगस्पॉट में, मैं सिर्फ मुख्य पृष्ठ पर गया, F-F (ओह, क्षमा करें, CTRL-F) दबाया और शीर्षकों में शब्दों के टुकड़े खोजे। यह इस बात के लिए है कि मैंने सही कॉलम में कुछ से लगभग सभी सूचनात्मक पोस्ट के लिंक प्रदर्शित करना शुरू कर दिया।

नए ब्लॉग में "काम करता है" सब कुछ उसी तरह से है जैसे पोस्ट के कैटलॉग के साथ पहले पृष्ठ पर। पदों को स्थानांतरित करते समय, मैंने कुछ के शीर्षकों को बदल दिया, जिससे उन्हें अधिक जानकारीपूर्ण और खोज योग्य बना दिया।

लेकिन! यह सब अब महत्वपूर्ण नहीं है, क्योंकि अब ब्लॉग पूर्ण-विशेषताओं वाली प्रासंगिक खोज चलाता है ।

चेकों

Jekyll की कष्टप्रद असुविधाओं में से एक किसी भी चीज के सत्यापन की कमी है। और मैं इसे पूरी तरह से Blogspot से पोस्ट खींचने और छोड़ने की प्रक्रिया से गुजरा। टूटी कड़ियाँ, गलत तारीखें, भूल गए उद्धरण, बिना चिह्नित भाषा और अन्य पोस्ट विशेषताएँ और बहुत कुछ। इसलिए, Goblog जहां भी संभव हो सब कुछ जांचता है - प्रारूप, लिंक, शब्दार्थ आदि। यदि कहीं पर कोई त्रुटि है, तो विधानसभा बंद हो जाती है। जब मैंने check_links () फ़ंक्शन को जोड़ा, जो पहले से ही इकट्ठे साइट में सभी फ़ाइलों के लिए सभी स्थानीय लिंक की जांच करता है, तो मैंने उचित मात्रा में मृत लिंक पकड़े।

दो भाषाएँ

एक समस्या यह भी थी कि, यह मुझे लगता है, बहुत ही शान्ति से हल करने में कामयाब रहा: द्विभाषावाद। मुझे एक ब्लॉग और एक द्विभाषी वेबसाइट की आवश्यकता है। लेकिन मैं किसी भी तरह रूसी और अंग्रेजी के लिए "पारदर्शी" समर्थन को हार्डकोड नहीं करना चाहता हूं, इसके अलावा, विभिन्न भाषाओं में संस्करण मौलिक रूप से भिन्न हो सकते हैं, और मेरे लिए स्वतंत्र रूप से अपने टेम्पलेट्स को बनाए रखना मुश्किल नहीं है। नतीजतन, मेरे पास प्रत्येक फ़ाइल (या पोस्ट) के लिए भाषा की अवधारणा है, जिसे संसाधित किया जा रहा है, हेडर में निर्दिष्ट है। गोब्लॉग को भाषाओं के बारे में जानकारी नहीं है। यह बस टेम्पलेट के माध्यम से फ़ाइल या पोस्ट के लिए भाषा की जानकारी उपलब्ध कराता है। और मैं खुद तय करता हूं कि फाइलें कहां हैं। उदाहरण के लिए, सभी रूसी साइट के मूल से शुरू होते हैं, और सभी अंग्रेजी में उपसर्ग " /english " है।

उदाहरण के लिए, रूसी कवर पेज और अंग्रेजी कवर पेज ।

मैं किस बात से संतुष्ट नहीं हूं

मुझे वेब प्रोग्रामिंग पसंद नहीं है: जावास्क्रिप्ट, सीएसएस, एचटीएमएल, और अधिक वेब डिज़ाइन नहीं है, जो मैं बिल्कुल भी नहीं कर पा रहा हूं। लेकिन यहाँ मुझे अभी भी इसमें तल्लीन होना पड़ा (ऑक्टोप्रेस के साथ यह आसान था)। मैंने एक आधार के रूप में लेखक जेकेल की साइट ली। सब कुछ न्यूनतम सरल बनाया। इसके अलावा, अधिकांश लोग अभी भी आरएसएस के माध्यम से पढ़ते हैं और साइट पर तभी जाते हैं जब वे एक टिप्पणी छोड़ना चाहते हैं। इसलिए, पढ़ने के लिए आरएसएस के लिए काम करना और पोस्ट पेज सुविधाजनक होना चाहिए (जिसका अर्थ है मेरे लिए सरल, बिना परिष्कृत फोंट और अजीब प्रारूप के)।

नैतिकता

क्या आपको लगता है कि अब मैं आपको अपने इंजन का उपयोग करने के लिए मनाऊंगा? बिलकुल नहीं। यद्यपि मैंने इंजन को लचीला बनाने और अपने ब्लॉग से विशेष रूप से अलग करने की कोशिश की, मुझे पुरानी पोस्ट और उनकी टिप्पणियों को स्थानांतरित करना पड़ा, दो भाषाओं का समर्थन करना, आदि। नतीजतन, मेरे ब्लॉग के लिए विशेष रूप से सिलवाया कोड में टुकड़े हैं (विशेष रूप से पुरानी पोस्ट पर टिप्पणियों के लिए डिस्कस-लिंक के क्षेत्र में)।

मैं केवल यह सुझाव दे सकता हूं कि आप व्यक्तिगत वेबसाइट / ब्लॉग के स्थिर इंजन को स्वयं लिख सकते हैं। क्यों? और क्योंकि यह समस्या कुछ शाम (समय) में हल हो गई है, और इसमें केवल वही होगा जिसकी आपको वास्तव में आवश्यकता है (बाकी आप प्रोग्राम के लिए बहुत आलसी होंगे) (दो)। मुझे यकीन है कि सब कुछ रूबी, और पायथन, पीएचपी, आदि पर किया जा सकता है। लेकिन एक वास्तविक कार्य के साथ नई भाषा का अभ्यास करने का अवसर चूकना मूर्खतापूर्ण था।

■

PS यह एक लगभग एक सप्ताह के लिए लिखा गया था, फिट और शुरू होता है। समानांतर में, मैंने एक खोज लिखी। अचानक, मुझे एहसास हुआ कि फिर भी कैसे यह गैर-समझदारी से एक ब्लॉग के साथ काम करने के लिए सुविधाजनक था। आप पृष्ठभूमि में एक पोस्ट लिखते हैं - आप एक शाखा में काम करते हैं, आप कार्यक्षमता जोड़ते हैं - दूसरी शाखा। जब कुछ तैयार होता है, तो मास्टर में विलीन हो जाता है और गिटहब पर जोर देता है। सौंदर्य।

गोब्लॉग: गो ब्लॉगिंग के लिए होममेड स्टेटिक इंजन