Goblog：Goブログ用の自家製静的エンジン

私はテキストを書くのが好きで、例をデバッグし、試して、分析するのが好きです。 気に入らないのは、書式設定、画像のアップロード、レイアウトの確認などです。



怠lazのため、私はBlogspotを使い始めました。 ここでは、テンプレートの海、あらゆる種類のウィジェット、Googleによるインスタントインデックス作成、統計情報が異なります。これは、コメントもツリーのようになったためです。 まあ、すべてがうまくいきますが、残念ながら、Blogspotエディターはプログラマーの投稿を作成するためのものではありません。 コードを埋め込む必要がある場合、またはテーブルが異なる場合、苦痛が始まります。 たとえば、私のブログでは、プログラミングに関するものではなく、 半熟卵、先生！ 、「機会」Blogspotで十分です。



また、元の投稿を、裸のHTML形式ではなく、通常の形式で保持したいと思います。 ブログの資料はあちこちに散らばっていることが判明しました。 まず、エディターでテキストを記述し、リンクと画像なしで段落に分割し、最後にほぼ完成したドキュメントを保存します。 次に、HTML組版が開始されます。その間、HTML自体に加えて、元のテキストが修正されます。 同時に、元のファイルの更新は既に面倒であり、実際、「生の」形式のままです。 また、「ドライ」形式では、HTMLのゴミのみが残ります。 しかし、これで話は終わりではありません。 多くの場合、発行後、タイプミスに気づき、Blogspotにアクセスして、ページ上で直接編集します。 繰り返しますが、最初のオリジナルとそのローカルのob-HTMLバージョンは修正されていません。 最後に：現在のバージョンの投稿はBlogspotのみにあります。 もちろん、ブログ全体の自動バックアップを作成することもできますが、これもまたすべてがHTMLのみで行われます。



しばらく前に、私はReSTを使い始めました 。 ここで、人生はどういうわけか気分が良くなりました。 ReSTを使用すると、多少予測可能なマークアップ（段落、リンク、コード）でテキストを記述でき、そこからHTMLが生成され、これが（再び手動で）Blogspotに挿入されます。 googleclを介して投稿のプレビューを自動化する試みは、実際には失敗しました。 繰り返しますが、ページ上のタイプミスを修正した後、ReSTの元のドキュメントが古くなった場合、問題は残りました。 さらに、ReSTは画像の問題を解決しませんでした。 完全にプレビューできるように、事前にどこかにレイアウトする必要がありました。



理由を説明することはできませんが、Wordpressのような動的エンジンのアイデアは、どういうわけかおびえました。 投稿をデータベースに保存するというアイデアは、やり過ぎだと思います。







vak.ruのように、例えばDoku Wikiなどの中間的な解決策にほぼすでに決まっています。 ここでは、エンジンは動的ですが、ページのコンテンツはファイルに保存され、バージョン管理があります。 Dokuは、ブログだけでなく、サイト全体のエンジンとして使用できます。 デザインはいですが、写真と任意の添付ファイルはシステムによってサポートされています。



TiddlyWikiに基づくブログ-私もほとんど購読している別のオプションがありました。 TiddlyWikiは、私のお気に入りのWindowsレコーディングツールです。 これについてはすでに書きました。 なぜWindowsのみですか？ Macでは、単純なテキストファイルでメモを作成し、ドキュメント内またはデスクトップ上にある意味でメモを作成します。Spotlightは、コンピューター上のすべてのものをインデックス付けし、単語の断片を即座に検索できるようにします。 TiddlyWikiの主要な機能であるインスタント検索はあまり意味をなさないことがわかりました。 しかし、気が散りました。



TiddlyWikiをブログプラットフォームに変えたファンがいることがわかりました。 静的-動的変異体の一種。



たとえば、このようなエンジンを備えたブログオプションは、 Rich SignellのWork Logです。 私の意見では、難解です。 たとえば、少なくとも同じDisqusでコメントを固定する方法は明確ではありません。 しかし、誰かが興味を持っているなら、公開ホスティング-tiddlyspotさえあります。



そして本当に、純粋に静的なエンジンのアイデアに興奮しました。 ここの美しさは、そのようなブログをどこでもホストできることです。 ここでは、データベースだけでなく、サーバー側のスクリプトも必要ありません。 しかし、さらに-もっと。 GitHubまたはHerokuを使用すると、静的サイトをホストできるだけでなく、gitを介してコンテンツを管理することもできます。



たとえば、静的なジキルエンジンがあります。 Jekyllでは、投稿はMarkdownまたはTextileマークアップを使用して記述されます。 プロジェクトに任意のファイルを追加することもできます。これは、サイトを生成するときに、変更なしでレイアウトされます。 実際、これはブログとしていくつかのファイルを設計できるサイトエンジンです。



コメントは、ブログの主要な「ダイナミクス」として、たとえばDisqusを通じて実装できます。 ところで、Zenの最高度の静的ブログには、 静的コメント （私にとっても、このフレーズは矛盾表現です）があります。 ここでのアプローチは次のとおりです。以下の投稿には、以前に入力したコメントが静的に表示されるセクションがあり、その隣に新しいコメントを入力するためのフォームがあります。 コメントを入力すると、ブログの作成者に送信されます。 それはそれを確認し（またはしない）、どこかをクリックし、コメントは静的なブログプロジェクトのファイルの形式で配置され、すべてが再構築されて公開されます。 これは決してリアルタイムではないことは明らかですが、事前調整を伴うコメントのようであり、モデレーターは週に一度連絡を取ります。



私は議論に本当に感謝しています。このアプローチは私には向いていません。 そして、私は引き続きDisqusを使用しています。 ちなみに、Disqusからコメントデータベースを完全にエクスポートできます。たとえば、突然それを離れる必要がある場合は、静的なページに変換できます。



しかし、ジキルに戻ります。 たとえば、GitHub PagesはJekyllを直接サポートし（その作成者はGitHubの共同設立者です）、Jekyllプロジェクトをレンダリングできます（ただし、ローカルでレンダリングできます）。 gitを介してJekyllプロジェクトに入力すると、GitHub Pagesにサイトが表示されます。



Herokuでは、考え方は少し異なります。 HerokuはRubyをホストしているため、Herokuの静的サイトはページ自体とそれらを提供するWebサーバープログラムです。 怖いように聞こえますが、Rubyではこのようなサーバーは非常にコンパクトに見えます。たとえば次のようになります。

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
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

奇妙なことに、Herokuでのホスティングは一般にGitHubでのホスティングよりも簡単です。 また、Herokuでは、ブログのgitリポジトリはプライベートのままですが、GitHubでは、他のすべてのプロジェクトと同様にオープンになります。 ブログプロジェクト（実際にはサイト）を閉じたままにしておくのは奇妙に聞こえますが。 彼はすでにウェブを通じて完全にアクセス可能です。



はい、GitHub PagesとHerokuの両方で、通常の第2レベルのドメイン（ある場合）を「ねじ込む」ことができます。



そこで、Herokuでホスティングするジキルを選びました。 残念ながら、純粋なJekyllを使用する場合は、スタイルとページレイアウトをゼロから設計する必要があります。 これが怠byによって行われる場合は、 Octopressを使用できます。



OctopressはJekyllに基づく静的なブログエンジンですが、美しいHTML5ページレイアウト、便利なプラグインの束、GitHub PagesとHerokuにブログを投稿する自動化機能を備えています。



そこで、Octopressを取り、前後にひねり、いくつかの投稿を試み、ブログのレンダリングをローカルでテストし、HerokuとGitHub Pagesにアップロードしました。 すべてが軟膏にあるように見えた。



次は、Marlezonバレエの最も退屈な部分でした。お気に入りのBlogspotから投稿をドラッグアンドドロップします。 実際、カットアンドペーストでこれを手動で行う必要がありました。 3週間の苦痛、そして私が処理した不幸な300件の投稿。



すべてが新しい静的ブログを立ち上げる準備ができました。 しかし、ここで主な失望が私を待っていました。 Rubyで書かれた貴重なJekyllが私の300の投稿を悲惨なものにしました（注意！）-15分（Mac Airで）。 そして、あなたが理解しているように、最初はたくさん試して、再組み立てし、再試行し、再組み立てする必要がありました。 そして、そのような完全な再組み立ての時期は、どの門にも登りませんでした。



pokeメソッドを使用して、私はJekyll / Octopressエンジンのボトルネックを発見しました。これらの15分の大部分は、 atom.xml



ファイル（RSSフィード）の生成にatom.xml



れました。 何らかの理由で、元のテンプレートでは、最後の20件の投稿のみがこのRSSファイルに含まれていました。 しかし、私は小さなブログを持っているので、そこにすべての投稿を含めました。そして、このファイルの生成時間はブログ全体の15分のビルドにつながりました。



これらはすべて、なんとなくばかげているように思えました（Rubyに対する私のすべての愛を込めて）。 少し考えて（その頃までにJekyllの内部構造をある程度理解していた）、Jekyllを高速化しようとするのを嫌がり、同様のアイデアで独自の静的エンジンを作成する必要があるのだろうか？ 結局のところ、これはファイル、テキスト、そして場合によってはテンプレートを扱うだけです。 さらに、ジキルにはどんな形の多言語も存在せず、そこにそれを追加する計画がありましたが、自分のエンジンで私の手は完全に解かれ、すべてが調和して美しくできます。



何に書きますか？ 男らしい：C ++ / boostで。 非常に高速に動作しますが、退屈です。 Goに決めました。 ネイティブで非常に高速なコンパイル（実際には、開始フェーズと組み合わされているため、コンパイルフェーズはありません）、文字列とファイルシステムの便利な作業、メモリ（ガベージコレクター）の簡略化された作業、正規表現、配列、ハッシュ、テンプレートのライブラリ、 Markdownのライブラリ 。 最後のものを除くすべては、箱から出してすぐです。 パフォーマンスの問題はまったくないはずです。 ここで、Go 1リリースが発表されたばかりで、現在はWindowsおよびMac用の通常のディストリビューションがあります。



それで、3晩後、私の自転車が生まれました-Goblog 。 プロジェクト全体が開いています。 サイトとそのソースは一緒です。

動作原理

主に2つの場所があります：プロジェクトと組み立てられたブログサイトです。 1つはソースファイルです。 アセンブリプロセス中に、ローカルディレクトリ構造を維持しながら、プロジェクトのファイルがアセンブリされたサイトにコピーされます。 デフォルトでは、ファイルはバイナリのように変更されずにコピーされます。 ファイルの拡張子がhtml



、 xml



またはjs



場合、このファイルはGoテンプレートシステムで実行されます 。 markdown



ダウン拡張子を持つファイルは、テンプレートの前にマークダウンライブラリによってさらに処理されます。



ディレクトリ：

• <root>
  
  
  
  は、 http：//demin.ws/で見られるように、組み立てられたサイトです。
• <root>/_engine
  
  
  
  これはプロジェクトです。ソースおよびサイトジェネレーターです。 技術的には、このディレクトリはWebからも見ることができます。

_engine



ディレクトリ内の_engine



ディレクトリとファイル：

• _includes
  
  
  
  マクロ{{include "filename"}}
  
  
  
  で置換できるファイル。
• _layouts
  
  
  
  ファイル（以下を参照）。
• _site
  
  
  
  実際には、ディレクトリとサイトファイル。 このディレクトリは、将来のサイトのルートです。 アセンブリ中のファイルは、アセンブリされたサイトに転送されます。 一部はテンプレートによって処理されます。
• _posts
  
  
  
  投稿のソース。 これらのファイルは特別に処理されます。 テンプレートに加えて、日付はURLの一部であるブログの構造に従って名前が変更されます。「 /blog/////-/
  
  
  
  」

投稿は、特別なタイトルと名前を持つマークダウンファイルです。 これらのファイルは、日付サブディレクトリを含む別の/blog



ディレクトリに配置されます。 投稿に関する情報は、テンプレートから表示される特別な変数に収集されます。 また、検索の逆インデックスは投稿に基づいています。

レイアウト

レイアウトの概念は、Jekyllから継承されています。 投稿またはページのヘッダーにlayout



属性がある場合（ たとえば ）、指定されたレイアウトテンプレート（ _layouts



ディレクトリから）が読み込まれてレンダリングされ、投稿またはページの本文が特定のレイアウトの場所に挿入されます（このPage.child Page.child



）その後、すべてが一緒にレンダリングされます。 これにより、類似したページのグループ（投稿など）を均一に配置できます。 レイアウトはネストできます。

発電機

そして今、実際には、ジェネレーターはmain.goです。



（ _engine



ディレクトリで）ビルドするために行うことは、 _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



関連する..



内）に、計算の準備ができているファイルが形成されます。 私のMac Airでは、組み立てに15秒かかります（hello、Jekyll / Octopress、さようなら）。 すべてがgitの下にあるため、どこでどのファイルが表示され、消え、変更されたかを常に明確に確認できます。



その後、サイトをローカルで確認できます（以下を参照）。



すべての準備が整ったら、変更されたファイル（ _site/



からのソースと収集されたファイルの両方）をローカルリポジトリに追加できます。



git add ../*

git commit -m "...に関する新しい投稿"



そして、GitHubページに配置します。



git push



push



ほぼ直後にpush



ファイルはdemin.wsに表示されます 。



Makefileには、作業を簡単にするための追加のコマンドがいくつかあります。

ローカルテスト

サイトをローカルで起動するには、一時的に「 127.0.0.1 demin.ws



」を/etc/hosts



追加し、ミニWebサーバーを起動します。 Rubyでどのように見えたか覚えていますか？ 小さいですね そして今、Goのバージョン（ server.go ）：

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

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

だから：

 go run server.go
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、サイトをローカルでテストできます（ポート80でsudo



を実行して「座る」必要がある場合があります）。



原則として、 /etc/hosts



触れてlocalhost:80



アドレスを使用することはできませんが、 atom.xml



RSSフィードにはドメインとの絶対リンクが含まれているため、RSSをテストする必要がある場合、なりすましなしでこれを行うことはできません。

構文の強調表示

Markdown拡張機能として、コードブロックを挿入するための特別なタグがあります。

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

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このタグはOctopressから継承しました。 Markdownにはすでにコードの構文があります：

 ``` xxx ... ```
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、 xxx



は言語です。



しかし、私のタグを使用すると、たとえば、行番号の表示、タブの変換など、属性を簡単に追加できます。



次に、構文の強調表示の問題を解決する必要がありました。 JavaScriptを直接ページ上で色付けするオンラインライブラリをいくつかねじりましたが、それぞれに最小限の問題があったため、コードを静的に色付けすることにしました。



最初に思いついたのは顔料です。 すべてうまくいきますが、Pythonのおかげで、動作が非常に遅くなります。 15秒からサイトの組み立てを完了するまでの時間が2分に増加しました。 ほとんどの時間はコードの色付けに費やされました。 すでに描かれた破片や他のゴミのキャッシュについて考えたが、短い検索の後、問題は根本的に解決された。



タスクに適した言語で記述されたカラライザーを使用する必要がありました。 Source-highlightとHighlightの 2つの選択肢が見つかりました。 どちらもC ++で記述されているため、ほとんど瞬時に機能します。



たとえば、ここで男性がpygmentsとsyntax-highlightのパフォーマンスを比較しました 。



ハイライトがもっと好きだった。 より多くの言語がサポートされています（たとえば、GNUのGoでもサポートされていません）。 ハイライトに切り替えた後、完全なアセンブリの時間は約15〜16秒に戻り、満足しました。



カラーライザーは、 {% codeblock %}



タグを処理する正規表現（コールバック（ ハイライト（）関数））を介して呼び出されました。

Markdownのエディター

Markdownのプレビューを備えたエディターでいっぱい。 WindowsではMarkdownPadを、MacではMarkedを使用しています。

タグ（カテゴリ）投稿

タグをまったく作成しないことにしました。 私自身の経験に基づいて、私は自分のブログでも見知らぬ人でもタグを使用しないことに気付きました。 さらに、時間の経過とともに、情報を分類するロジックに対する見解が変わり、場合によっては、過去との互換性のポイントが表示されなくなったタグを配置するだけで済む場合があります。 たとえば、私のブログのc++



タグのポイントは何ですか？ 誰もそれを使ったことがありますか？



しかし、ミニマリズムは人生を複雑にする方法ではありません。 それどころか。 個人的に、私はブログの古い投稿で常に何かを探しています。 Blogspotでは、メインページに移動し、⌘-F（ああ、申し訳ありませんが、CTRL-F）を押して、見出しの単語の断片を検索しました。 このために、右側の列のいくつかからのほとんどすべての有益な投稿へのリンクを表示し始めました。



新しいブログでは、最初のページで投稿のカタログと同じようにすべてが「機能」します。 投稿を転送するときに、一部の見出しを変更し、より有益で検索しやすくしました。



しかし！ 現在、ブログはフル機能のコンテキスト検索を実行しているため、これはもはや重要ではありません。

チェック

Jekyllの迷惑な不便の1つは、何も検証されていないことです。 そして、これをBlogspotから投稿をドラッグアンドドロップするプロセスで完全に試しました。 壊れたリンク、誤った日付、引用を忘れた、マークされていない言語、その他の投稿属性など。 したがって、Goblogは可能な限りすべてをチェックします-フォーマット、リンク、セマンティクスなど。 どこかにエラーがある場合、アセンブリは停止します。 check_links（）関数を追加すると、既にアセンブルされたサイト内のすべてのファイルのすべてのローカルリンクがチェックされ、かなりの量のデッドリンクが見つかりました。

2つの言語

私には、非常にエレガントに解決できたという問題もありました。それはバイリンガリズムです。 ブログとバイリンガルのウェブサイトが必要です。 しかし、ロシア語と英語の「透明な」サポートをハードコードしたくはありませんでした。さらに、異なる言語のバージョンは根本的に異なる可能性があり、テンプレートを個別に維持することは難しくありません。 その結果、ヘッダーで指定された、処理されている各ファイル（または投稿）の言語の概念があります。 Goblogは言語については知りません。 ファイルまたは投稿の言語情報をテンプレートから利用できるようにします。 そして、私自身がファイルの場所を決めます。 たとえば、すべてのロシア語はサイトのルートから始まり、すべての英語には接頭辞「 /english



」が付いています。



たとえば、 ロシアの表紙と英語の表紙 。

満足していないもの

私はWebプログラミングが好きではありません：javascript、css、html、そしてWebデザインはもうありません。 しかし、ここではまだこれを掘り下げなければなりませんでした（Octopressの方が簡単でした）。 著者のJekyllのサイトを基礎として取り上げました。 すべてを最小限にシンプルにしました。 さらに、ほとんどの人はまだコメントを残したい場合にのみRSSを読んでサイトにアクセスします。 そのため、RSSが機能し、投稿ページが読みやすい（洗練されたフォントや奇妙な書式設定が不要な私にとってシンプルな）必要があります。

道徳

私のエンジンを今すぐ使用するように説得すると思いますか？ まったくありません。 エンジンを柔軟でブログから切り離すようにしようとしましたが、古い投稿とそのコメントを転送し、2つの言語をサポートする必要がありました。 その結果、私のブログ用に特別に調整されたコードの一部があります（特に、古い投稿のコメントへのDisqusリンクの領域）。



個人のウェブサイト/ブログの静的エンジンを自分で書くことをお勧めします。 なんで？ そして、この問題は数晩（時間）で解決され、本当に必要なものだけが残ります（残りはプログラムするのが面倒になります）（2）。 Ruby、Python、PHPなどですべてを実行できると確信しています。 しかし、新しい言語を実際のタスクで練習する機会を逃すのは愚かでした。



■



PSこの1つは、ほぼ1週間、はめあいと開始のために書かれました。 並行して、検索を作成しました。 突然、Gitを使用してブログを操作することが非現実的に便利であることに気付きました。 バックグラウンドで投稿を作成します-あるブランチで作業し、機能を追加します-別のブランチ。 準備ができたら、masterにマージしてGitHubをプッシュします。 美人