Goblog: Homemade Static Engine for Go Blogging
I like to write texts, I like to debug examples, try, analyze. What I don’t like is messing around with formatting, uploading pictures, checking layouts, etc.
Due to laziness, I started using Blogspot. Here you and the sea of templates, all kinds of widgets, instant indexing by Google, the statistics are different, since some time even comments have become tree-like, and other whistles. Well, everything would be fine, but, alas, the Blogspot editor is not intended for creating programmer posts. When you need to embed code or tables are different, torment begins. For example, for my other blog, not about programming, soft-boiled eggs, sir! , "Opportunities" Blogspot is enough.
I also want to keep the original posts in a normal, not caked HTML form. It turned out that the blog material was scattered here and there in several copies. At first you just write the text in the editor, only breaking it into paragraphs, without links and pictures, and at the end you save the almost finished document. Then HTML typesetting begins, during which, in addition to HTML, in fact, amendments are made to the original text. At the same time, updating the original file is already too lazy, and in fact, it remains in a "raw" form. And in the “dry” form, only the HTML garbage remains. But this is not the end of the story. Often after publication, you notice a typo, climb into Blogspot and edit right on the page. Again, the very first original and its local ob-HTML version remain uncorrected. Eventually: actual versions of posts are only on Blogspot itself. Of course, you can make an automated backup of the entire blog, but again, everything will be in HTML only.
Some time ago I started using ReST . Here, life somehow felt better. ReST allows you to write text in more or less predictable markup (paragraphs, links, code), and then HTML is generated from it, which is inserted (again manually) into Blogspot. Attempts to automate the preview of the post via googlecl have actually failed. Again, the problem remained when, after correcting a typo on the page, the original document in ReST was out of date. In addition, ReST did not solve the picture problem. They had to be laid out somewhere in advance, so that you could completely preview.
I can’t explain why, but the idea of dynamic engines like Wordpress somehow frightened me. The very idea of keeping posts in the database seems to me overkill.
I almost was already stopped on the interim solution - Doku Wiki edits , such as vak.ru . Here, although the engine is dynamic, the content of the pages is stored in files, and there is versioning. Doku can be used as the engine of the entire site, not just a blog. Although the design is ugly, but the pictures and arbitrary attachments are supported by the system.
There was another option that I almost subscribed to - a blog based on TiddlyWiki . TiddlyWiki is my favorite Windows recording tool. I already wrote about this . Why only on Windows? Because on the Mac, I just make notes in simple text files, placing them in the sense in documents or on the desktop, and Spotlight, which indexes everything and everything on the computer, instantly allows you to search for fragments of words. It turns out that the key features of TiddlyWiki - instant search, no longer make much sense. But I was distracted.
Turns out there are fans who have turned TiddlyWiki into a blogging platform. In a kind of static-dynamic mutant.
For example, a blog option with such an engine is Rich Signell's Work Log . Esoteric, in my opinion. For example, it is not clear how to fasten comments, at least the same Disqus. But if anyone is interested, there is even a public hosting - tiddlyspot .
And really, I got excited about the idea of purely static engines. The beauty here is that you can host such a blog anywhere. Here, not only the database is not needed, but also server-side scripting. But further - more. GitHub or Heroku allow you to not only host static sites, but also manage content through git.
For example, there is a static Jekyll engine . In Jekyll, posts are written using Markdown or Textile markup. You can also add arbitrary files to the project, which, when generating the site, will be laid out without changes. In fact, this is a site engine where you can still design some files as a blog.
Comments, as the main "dynamics" of the blog, can be implemented through, for example, Disqus. By the way, there are esthetes of static blogs with the highest degree of zen - with static comments (for me, even this phrase is an oxymoron). The approach here is this: the post below has a section with statically displayed previously entered comments, and next to it is a form for entering a new one. You enter a comment and it is sent to the author of the blog. He confirms it (or not), clicks somewhere, and the comment is placed in the form of a file in a static blog project, everything is reassembled and laid out to the public. It is clear that this is never real-time, but more like comments with pre-moderation, and the moderator gets in touch once a week.
I really appreciate the discussion, and this approach is not for me. And I continue to use Disqus. By the way, from Disqus you can perfectly export the comment database, and, for example, turn it into static pages if you suddenly have to leave it.
But back to Jekyll. For example, GitHub Pages directly supports Jekyll (its author is the co-founder of GitHub) and can render Jekyll projects (although you can render it locally yourself). You fill in the Jekyll project through git, and the site becomes visible in GitHub Pages.
At Heroku, the idea is a bit different. Heroku hosts Ruby, so the static site on Heroku is the pages themselves and the web server program that gives them away. It sounds scary, but on Ruby this server looks very compact, for example like this:
Oddly enough, hosting on Heroku is generally simpler than on GitHub. Also, on Heroku, the blog git repository remains private, while on GitHub it becomes open, like all other projects. Although it sounds strange to me to keep the blog project (in fact, the site) closed. He is already fully accessible through the web.
Yes, both GitHub Pages and Heroku allow you to "screw" a normal second-level domain, if you have one.
So, I chose Jekyll with hosting on Heroku. Alas, if you take pure Jekyll, you will have to design styles and page layout yourself from scratch. If you are too lazy to do this, then you can take Octopress .
Octopress is a static blog engine based on Jekyll, but which is equipped with beautiful HTML5 page layout, a bunch of handy plug-ins and the automated ability to post a blog on GitHub Pages and Heroku.
So, I took Octopress, twisted it back and forth, tried several posts, tested the rendering of the blog locally, posted it on Heroku and GitHub Pages. Everything seemed to be on the ointment.
Next was the most tedious part of the Marlezon ballet - drag and drop posts from your favorite Blogspot. In fact, I had to do this manually through cut-and-paste. Three weeks of torment, and my unhappy three hundred posts I processed.
Everything was ready to launch my new static blog. But here the main disappointment awaited me. The precious Jekyll, written in Ruby, rendered my miserable three hundred posts (attention!) - 15 minutes (on Mac Air). And as you understand, in the beginning it was necessary to try a lot, reassemble, try again, reassemble, etc. And such a time of complete reassembly did not climb into any gate.
Using the poke method, I found a bottleneck in the Jekyll / Octopress engine - the lion's share of these 15 minutes went into generating the file
All this seemed to me somehow absurd (with all my love for Ruby). After a little thought (by that time I already understood Jekyll's insides more or less) and reluctance to keep Jekyll in an attempt to speed it up, I wondered if I should write my own static engine on a similar idea? After all, this is just work with files, text, and possibly templates. In addition, in Jekyll there is no multilingualism in any form, and I had plans to add it there, but with my own engine my hands are completely untied, and everything can be done in a harmonious and beautiful way.
What to write on? It is possible manly: on C ++ / boost. It will work very fast, but boring. I decided on Go. Native, very fast compilation (in fact, I do not have a compilation phase, since it is combined with the start phase), convenient work with strings and the file system, simplified work with memory (garbage collector), regular expressions, arrays, hashes, a library of templates, library for Markdown . Everything except the last is out of the box. There should not be any performance problems at all. Here the Go 1 release was just released, and now there are normal distributions for Windows and Mac.
So, after three evenings, my bike was born - Goblog . The whole project is open. The site and its sources are together.
There are two main places: the project and the assembled blog site. The first is the source files. During the assembly process, files from the project are copied to the assembled site while maintaining the local directory structure. By default, files are copied unchanged, like binary. If any file has the extension
Directories:
Subdirectories and files in a directory
Posts are Markdown files with a special title and name. These files are laid out in a separate directory
The idea of layouts is inherited from Jekyll. If the post or page has an attribute in the title
And now, in fact, the generator - main.go .
All I do for assembly (in the directory
The following is displayed:
If all is well, then files are prepared in the project root (in the directory
Then you can check the site locally (see below).
If everything is ready, you can add the modified files (both sources from
git add ../*
git commit -m “New post about ...”
And put it on GitHub Pages:
git push
Almost immediately after the
In makefile A few extra commands to make life easier.
To start the site locally, I temporarily add a "
So:
And you can test the site locally (you may have to run through
In principle, you can not touch
As a Markdown extension, I have a special tag for inserting blocks of code:
I inherited this tag from Octopress. Markdown already has the syntax for the code:
where
But my tag makes it easier for me to add attributes, for example, enabling the display of line numbers, converting tabs, etc.
Next, it was necessary to solve the issue of syntax highlighting. I twisted several online libraries that color through JavaScript directly on the page, but each had some minimal problem, so I decided to color the code statically.
The first thing that came to mind was pygments . Everything would be fine, but thanks to Python, it works extremely slowly. The time to complete the assembly of the site from 15 seconds increased to two minutes. Most of the time was spent on coloring the code. Thoughts came about the cache of already painted fragments and other nonsense, but after a short search the problem was solved radically.
You just had to take a colorizer written in the correct language for the task. Two alternatives were found: Source-highlight and Highlight . Both are written in C ++, so they work almost instantly.
For example, here a man compared the performance of pygments and syntax-highlight .
I liked Highlight more. There are more languages supported in it (for example, in GNU's, even Go is not). After switching to Highlight, the time of full assembly returned to ~ 15-16 seconds, and I was satisfied.
The colorizer was called through a callback in the regular expression that processes the tag
Full of editors with preview for Markdown. I use MarkdownPad on Windows, and Marked on Mac.
I decided not to make tags at all. Based on my own experience, I realized that I never use tags either on my blog or on strangers. In addition, over time, the views on the logic of categorizing information change, and sometimes you just have to put tags in which you no longer see the point for compatibility with the past. What, for example, is the meaning of a tag
But minimalism is not a way to complicate life. On the contrary. Personally, I am constantly looking for something on my blog in old posts. At Blogspot, I just went to the main page, pressed ⌘-F (oh, sorry, CTRL-F) and searched for fragments of words in the headings. It is for this that I began to display links to almost all informative posts from some in the right column.
Everything “works” in the new blog in the same way right on the first page with the catalog of posts. When transferring posts, I changed the headings of some, making them more informative and searchable.
But! All this is no longer important, since now the blog runs a full-featured contextual search .
One of Jekyll's annoying inconveniences is the lack of any verification of anything. And I went through this fully in the process of dragging and dropping posts from Blogspot. Broken links, incorrect dates, forgotten quotes, unmarked languages and other post attributes and much more. Therefore, Goblog checks everything wherever possible - formats, links, semantics, etc. If there is an error somewhere, the assembly stops. When I added the check_links () function , which checks all local links for all files in an already built site, I caught a fair amount of dead links.
There was also a problem that, it seems to me, was managed to be solved very elegantly: bilingualism. I need a blog and a bilingual website. But somehow I didn’t want to hardcode “transparent” support for Russian and English, besides, versions in different languages can be radically different, and it’s not difficult for me to maintain their templates independently. As a result, I just have the concept of language for each file (or post) being processed, specified in the header. Goblog does not know about languages. It simply makes the language information for the file or post available through templates. And I myself decide where what files are. For example, all Russian lies, starting with the root of the site, and all English has the prefix "
For example, the Russian cover page and the English cover page .
I do not like web-programming: javascript, css, html, and there is no more web-design, which I am not able to do at all. But here I still had to delve into this (with Octopress it was easier). I took the site of the author Jekyll as a basis . Made everything minimalistically simple. In addition, most people still read via RSS and go to the site only if they want to leave a comment. Therefore, it is necessary for RSS to work and the post page to be convenient (which means simple for me, without sophisticated fonts and strange formatting) for reading.
Do you think I’ll convince you to use my engine now? Not at all. Although I tried to make the engine as flexible and detached specifically from my blog, I had to transfer old posts and their comments, support two languages, etc. As a result, there are pieces in the code tailored specifically for my blog (especially in the area of Disqus-links to comments on old posts).
I can only recommend that you can write the static engine of a personal website / blog yourself. Why? But because this problem is solved in a few evenings (times), and it will only have what you really need (the rest you will be too lazy to program) (two). I am sure that everything could be done on Ruby, and on Python, PHP, etc. But it was foolish to miss the opportunity to practice the new language with a real task.
■
PS This one was written for almost a week, in fits and starts. In parallel, I wrote a search. Suddenly I realized how nevertheless it is unrealistically convenient to work with a blog with git. You write a post in the background - you work in one branch, you add functionality - another branch. When something is ready, merges into master and push on GitHub. Beauty.
Due to laziness, I started using Blogspot. Here you and the sea of templates, all kinds of widgets, instant indexing by Google, the statistics are different, since some time even comments have become tree-like, and other whistles. Well, everything would be fine, but, alas, the Blogspot editor is not intended for creating programmer posts. When you need to embed code or tables are different, torment begins. For example, for my other blog, not about programming, soft-boiled eggs, sir! , "Opportunities" Blogspot is enough.
I also want to keep the original posts in a normal, not caked HTML form. It turned out that the blog material was scattered here and there in several copies. At first you just write the text in the editor, only breaking it into paragraphs, without links and pictures, and at the end you save the almost finished document. Then HTML typesetting begins, during which, in addition to HTML, in fact, amendments are made to the original text. At the same time, updating the original file is already too lazy, and in fact, it remains in a "raw" form. And in the “dry” form, only the HTML garbage remains. But this is not the end of the story. Often after publication, you notice a typo, climb into Blogspot and edit right on the page. Again, the very first original and its local ob-HTML version remain uncorrected. Eventually: actual versions of posts are only on Blogspot itself. Of course, you can make an automated backup of the entire blog, but again, everything will be in HTML only.
Some time ago I started using ReST . Here, life somehow felt better. ReST allows you to write text in more or less predictable markup (paragraphs, links, code), and then HTML is generated from it, which is inserted (again manually) into Blogspot. Attempts to automate the preview of the post via googlecl have actually failed. Again, the problem remained when, after correcting a typo on the page, the original document in ReST was out of date. In addition, ReST did not solve the picture problem. They had to be laid out somewhere in advance, so that you could completely preview.
I can’t explain why, but the idea of dynamic engines like Wordpress somehow frightened me. The very idea of keeping posts in the database seems to me overkill.
I almost was already stopped on the interim solution - Doku Wiki edits , such as vak.ru . Here, although the engine is dynamic, the content of the pages is stored in files, and there is versioning. Doku can be used as the engine of the entire site, not just a blog. Although the design is ugly, but the pictures and arbitrary attachments are supported by the system.
There was another option that I almost subscribed to - a blog based on TiddlyWiki . TiddlyWiki is my favorite Windows recording tool. I already wrote about this . Why only on Windows? Because on the Mac, I just make notes in simple text files, placing them in the sense in documents or on the desktop, and Spotlight, which indexes everything and everything on the computer, instantly allows you to search for fragments of words. It turns out that the key features of TiddlyWiki - instant search, no longer make much sense. But I was distracted.
Turns out there are fans who have turned TiddlyWiki into a blogging platform. In a kind of static-dynamic mutant.
For example, a blog option with such an engine is Rich Signell's Work Log . Esoteric, in my opinion. For example, it is not clear how to fasten comments, at least the same Disqus. But if anyone is interested, there is even a public hosting - tiddlyspot .
And really, I got excited about the idea of purely static engines. The beauty here is that you can host such a blog anywhere. Here, not only the database is not needed, but also server-side scripting. But further - more. GitHub or Heroku allow you to not only host static sites, but also manage content through git.
For example, there is a static Jekyll engine . In Jekyll, posts are written using Markdown or Textile markup. You can also add arbitrary files to the project, which, when generating the site, will be laid out without changes. In fact, this is a site engine where you can still design some files as a blog.
Comments, as the main "dynamics" of the blog, can be implemented through, for example, Disqus. By the way, there are esthetes of static blogs with the highest degree of zen - with static comments (for me, even this phrase is an oxymoron). The approach here is this: the post below has a section with statically displayed previously entered comments, and next to it is a form for entering a new one. You enter a comment and it is sent to the author of the blog. He confirms it (or not), clicks somewhere, and the comment is placed in the form of a file in a static blog project, everything is reassembled and laid out to the public. It is clear that this is never real-time, but more like comments with pre-moderation, and the moderator gets in touch once a week.
I really appreciate the discussion, and this approach is not for me. And I continue to use Disqus. By the way, from Disqus you can perfectly export the comment database, and, for example, turn it into static pages if you suddenly have to leave it.
But back to Jekyll. For example, GitHub Pages directly supports Jekyll (its author is the co-founder of GitHub) and can render Jekyll projects (although you can render it locally yourself). You fill in the Jekyll project through git, and the site becomes visible in GitHub Pages.
At Heroku, the idea is a bit different. Heroku hosts Ruby, so the static site on Heroku is the pages themselves and the web server program that gives them away. It sounds scary, but on Ruby this server looks very compact, for example like this:
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 =~ /\.[a-z]+$/i
File.exist?(file_path) ? send_file(file_path) : missing_file_block.call
end
end
run SinatraStaticServer
Oddly enough, hosting on Heroku is generally simpler than on GitHub. Also, on Heroku, the blog git repository remains private, while on GitHub it becomes open, like all other projects. Although it sounds strange to me to keep the blog project (in fact, the site) closed. He is already fully accessible through the web.
Yes, both GitHub Pages and Heroku allow you to "screw" a normal second-level domain, if you have one.
So, I chose Jekyll with hosting on Heroku. Alas, if you take pure Jekyll, you will have to design styles and page layout yourself from scratch. If you are too lazy to do this, then you can take Octopress .
Octopress is a static blog engine based on Jekyll, but which is equipped with beautiful HTML5 page layout, a bunch of handy plug-ins and the automated ability to post a blog on GitHub Pages and Heroku.
So, I took Octopress, twisted it back and forth, tried several posts, tested the rendering of the blog locally, posted it on Heroku and GitHub Pages. Everything seemed to be on the ointment.
Next was the most tedious part of the Marlezon ballet - drag and drop posts from your favorite Blogspot. In fact, I had to do this manually through cut-and-paste. Three weeks of torment, and my unhappy three hundred posts I processed.
Everything was ready to launch my new static blog. But here the main disappointment awaited me. The precious Jekyll, written in Ruby, rendered my miserable three hundred posts (attention!) - 15 minutes (on Mac Air). And as you understand, in the beginning it was necessary to try a lot, reassemble, try again, reassemble, etc. And such a time of complete reassembly did not climb into any gate.
Using the poke method, I found a bottleneck in the Jekyll / Octopress engine - the lion's share of these 15 minutes went into generating the file
atom.xml, the RSS feed. For some reason, in the original templates, only the last twenty posts were included in this RSS file. But I have a small blog, so I included all the posts there, and then the generation time of this file led to a fifteen minute build of the entire blog.All this seemed to me somehow absurd (with all my love for Ruby). After a little thought (by that time I already understood Jekyll's insides more or less) and reluctance to keep Jekyll in an attempt to speed it up, I wondered if I should write my own static engine on a similar idea? After all, this is just work with files, text, and possibly templates. In addition, in Jekyll there is no multilingualism in any form, and I had plans to add it there, but with my own engine my hands are completely untied, and everything can be done in a harmonious and beautiful way.
What to write on? It is possible manly: on C ++ / boost. It will work very fast, but boring. I decided on Go. Native, very fast compilation (in fact, I do not have a compilation phase, since it is combined with the start phase), convenient work with strings and the file system, simplified work with memory (garbage collector), regular expressions, arrays, hashes, a library of templates, library for Markdown . Everything except the last is out of the box. There should not be any performance problems at all. Here the Go 1 release was just released, and now there are normal distributions for Windows and Mac.
So, after three evenings, my bike was born - Goblog . The whole project is open. The site and its sources are together.
Principle of operation
There are two main places: the project and the assembled blog site. The first is the source files. During the assembly process, files from the project are copied to the assembled site while maintaining the local directory structure. By default, files are copied unchanged, like binary. If any file has the extension
html, xmlor js, then this file is run through the Go template system . Files with the extension, in markdownaddition to the templates, are processed by the Markdown library. Directories:
/_engine
Subdirectories and files in a directory
_engine:_includes- Files that can be substituted through a macro{{include "filename"}}._layouts- Layout files (see below)._site- Actually, directories and site files. This directory is the root of the future site. Files from it during assembly are transferred to the assembled site. Some are handled by templates._posts- Sources of posts. These files are processed specially. In addition to templates, they are renamed according to the structure of the blog, where the date is part of the URL: "домен/blog/язык/год/месяц/день/название-поста/"
Posts are Markdown files with a special title and name. These files are laid out in a separate directory
/blogwith date subdirectories. Information about posts is collected in special variables that are made visible from templates. Also, a reverse index for search is built on posts .Layouts
The idea of layouts is inherited from Jekyll. If the post or page has an attribute in the title
layout( for example ), then the specified layout template (from the catalog _layouts) is loaded to render it , the body of the post or page is inserted into a specific layout location (I have a placeholder Page.child), and then everything is rendered together. This allows you to uniformly arrange groups of similar pages (for example, posts). Layouts can be nested.Generator
And now, in fact, the generator - main.go .
All I do for assembly (in the directory
_engine) is:make
The following is displayed:
_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.
If all is well, then files are prepared in the project root (in the directory
..relatively _engine), ready for calculation. On my Mac Air, assembly takes 15 seconds (hello, Jekyll / Octopress, and goodbye). Since everything is under git, you can always clearly see where and which files appeared, disappeared or changed. Then you can check the site locally (see below).
If everything is ready, you can add the modified files (both sources from
_site/and collected files) to the local repository: git add ../*
git commit -m “New post about ...”
And put it on GitHub Pages:
git push
Almost immediately after the
pushfiles appear on demin.ws . In makefile A few extra commands to make life easier.
Local testing
To start the site locally, I temporarily add a "
127.0.0.1 demin.ws" to /etc/hostsand start the mini web server. Remember what it looked like in Ruby? Small, right? And now the version on Go ( server.go ):package main
import "net/http"
func main() {
panic(http.ListenAndServe(":80", http.FileServer(http.Dir(".."))))
}
So:
go run server.go
And you can test the site locally (you may have to run through
sudoto "sit down" on port 80). In principle, you can not touch
/etc/hostsand use the address localhost:80, but the RSS feed atom.xmlcontains absolute links with the domain, so if you need to test RSS, then you can’t do without address spoofing.Syntax highlighting
As a Markdown extension, I have a special tag for inserting blocks of code:
{% codeblock lang:xxx %}
...
{% endcodeblock %}
I inherited this tag from Octopress. Markdown already has the syntax for the code:
``` xxx
...
```
where
xxxis the language. But my tag makes it easier for me to add attributes, for example, enabling the display of line numbers, converting tabs, etc.
Next, it was necessary to solve the issue of syntax highlighting. I twisted several online libraries that color through JavaScript directly on the page, but each had some minimal problem, so I decided to color the code statically.
The first thing that came to mind was pygments . Everything would be fine, but thanks to Python, it works extremely slowly. The time to complete the assembly of the site from 15 seconds increased to two minutes. Most of the time was spent on coloring the code. Thoughts came about the cache of already painted fragments and other nonsense, but after a short search the problem was solved radically.
You just had to take a colorizer written in the correct language for the task. Two alternatives were found: Source-highlight and Highlight . Both are written in C ++, so they work almost instantly.
For example, here a man compared the performance of pygments and syntax-highlight .
I liked Highlight more. There are more languages supported in it (for example, in GNU's, even Go is not). After switching to Highlight, the time of full assembly returned to ~ 15-16 seconds, and I was satisfied.
The colorizer was called through a callback in the regular expression that processes the tag
{% codeblock %}( highlight () function ).Editors for Markdown
Full of editors with preview for Markdown. I use MarkdownPad on Windows, and Marked on Mac.
Tags (categories) posts
I decided not to make tags at all. Based on my own experience, I realized that I never use tags either on my blog or on strangers. In addition, over time, the views on the logic of categorizing information change, and sometimes you just have to put tags in which you no longer see the point for compatibility with the past. What, for example, is the meaning of a tag
c++on my blog? Has anyone ever used it? But minimalism is not a way to complicate life. On the contrary. Personally, I am constantly looking for something on my blog in old posts. At Blogspot, I just went to the main page, pressed ⌘-F (oh, sorry, CTRL-F) and searched for fragments of words in the headings. It is for this that I began to display links to almost all informative posts from some in the right column.
Everything “works” in the new blog in the same way right on the first page with the catalog of posts. When transferring posts, I changed the headings of some, making them more informative and searchable.
But! All this is no longer important, since now the blog runs a full-featured contextual search .
Checks
One of Jekyll's annoying inconveniences is the lack of any verification of anything. And I went through this fully in the process of dragging and dropping posts from Blogspot. Broken links, incorrect dates, forgotten quotes, unmarked languages and other post attributes and much more. Therefore, Goblog checks everything wherever possible - formats, links, semantics, etc. If there is an error somewhere, the assembly stops. When I added the check_links () function , which checks all local links for all files in an already built site, I caught a fair amount of dead links.
Two languages
There was also a problem that, it seems to me, was managed to be solved very elegantly: bilingualism. I need a blog and a bilingual website. But somehow I didn’t want to hardcode “transparent” support for Russian and English, besides, versions in different languages can be radically different, and it’s not difficult for me to maintain their templates independently. As a result, I just have the concept of language for each file (or post) being processed, specified in the header. Goblog does not know about languages. It simply makes the language information for the file or post available through templates. And I myself decide where what files are. For example, all Russian lies, starting with the root of the site, and all English has the prefix "
/english". For example, the Russian cover page and the English cover page .
What am I not satisfied with
I do not like web-programming: javascript, css, html, and there is no more web-design, which I am not able to do at all. But here I still had to delve into this (with Octopress it was easier). I took the site of the author Jekyll as a basis . Made everything minimalistically simple. In addition, most people still read via RSS and go to the site only if they want to leave a comment. Therefore, it is necessary for RSS to work and the post page to be convenient (which means simple for me, without sophisticated fonts and strange formatting) for reading.
Morality
Do you think I’ll convince you to use my engine now? Not at all. Although I tried to make the engine as flexible and detached specifically from my blog, I had to transfer old posts and their comments, support two languages, etc. As a result, there are pieces in the code tailored specifically for my blog (especially in the area of Disqus-links to comments on old posts).
I can only recommend that you can write the static engine of a personal website / blog yourself. Why? But because this problem is solved in a few evenings (times), and it will only have what you really need (the rest you will be too lazy to program) (two). I am sure that everything could be done on Ruby, and on Python, PHP, etc. But it was foolish to miss the opportunity to practice the new language with a real task.
■
PS This one was written for almost a week, in fits and starts. In parallel, I wrote a search. Suddenly I realized how nevertheless it is unrealistically convenient to work with a blog with git. You write a post in the background - you work in one branch, you add functionality - another branch. When something is ready, merges into master and push on GitHub. Beauty.