Содер­жа­ние:

• Крат­кая инфор­ма­ция
• Немного подроб­но­стей
• Более ран­ние попытки
• Про­чие детали (оформ­ле­ние, пла­гины, etc)
• Фор­мулы
• Кон­тей­неры
• Вор­ча­ние
  • Аль­тер­на­тивы
  • Ещё вор­ча­ние
• Заклю­че­ние
• Ссылки

Крат­кая инфор­ма­ция

Неболь­шой пер­со­наль­ный «блог» (пуб­лич­ный сете­вой днев­ник). Тема­тика запи­сей по плану вклю­чает в себя изло­же­ние обры­воч­ных мыс­лей и идей по про­грам­ми­ро­ва­нию, радио­лю­би­тель­ской прак­тике, про­стой элек­тро­нике, и вообще зани­ма­тель­ной науке.

Немного подроб­но­стей

Мате­ри­алы оформ­лены с при­ме­не­нием языка раз­метки Markdown (а точ­нее говоря, его вари­анта, commonmark, хотя раньше я успешно при­ме­нял вари­ант, под­дер­жи­ва­е­мый кон­вер­те­ром kramdown+GFM, в какой-то момент пере­став­шим рабо­тать без види­мых при­чин; потом пытался исполь­зо­вать кон­вер­тер redcarpet, но тоже не очень удачно) и раз­ме­щены на халяву небезыз­вест­ном ресурсе GitHub с исполь­зо­ва­нием ста­ти­че­ского гене­ра­тора Jekyll в связке с функ­ци­о­наль­но­стью непре­рыв­ной инте­гра­ции, предо­став­ля­е­мой [отно­си­тельно новым] меха­низ­мом GitHub Actions (для под­держки про­из­воль­ных моду­лей рас­ши­ре­ния — пла­ги­нов — Jekyll, в част­но­сти, пла­ги­нов под­держки -формул, по невнят­ным при­чи­нам отклю­чен­ных во встро­ен­ном в GitHub Pages и рабо­та­ю­щем в без­опас­ном режиме Jekyll-генераторе).

(Ста­тич­ность {или услов­ная, «пе­ре­ход­ная» ста­тич­ность, с уче­том исполь­зо­ва­ния гене­ра­ции на сто­роне сервера} может пока­заться пере­жит­ком девя­но­стых годов, но это — вполне адек­ват­ное реше­ние для неболь­шого бло­га; из огра­ни­че­ний такого под­хода в первую оче­редь сле­дует назвать невоз­мож­ность орга­ни­зо­вать, e.g., пол­но­тек­сто­вый поиск и обрат­ную связь посред­ством раз­ме­ща­е­мых чита­те­лями и пуб­ли­ку­е­мых [полу]автоматически ком­мен­та­риев {эти огра­ни­че­ния имеют свои обход­ные пути реше­ния с исполь­зо­ва­нием сто­рон­них сер­ви­сов и кли­ент­ских сценариев}. Если не нужны поиск {из-за малого раз­мера блога} и ком­мен­та­рии {в силу необ­хо­ди­мо­сти их, воз­можно обре­ме­ни­тель­ной, [пре]модерации}, то и гене­ра­ция стра­ниц, напри­мер cgi-скриптом, при каж­дом запросе всё-равно будет изли­ше­ством.)

Более ран­ние попытки

До этого я пытался исполь­зо­вать сто­рон­ние сер­висы непре­рыв­ной инте­гра­ции (CI/CD) вроде Travis CI, Circle CI и неко­то­рые дру­гие, но для верстки ста­тич­ного блога это кажется пере­бо­ром (к тому же, web-интерфейсы Circle CI, и в осо­бен­но­сти Travis CI, немного не дру­жат с исполь­зу­е­мыми мною web-обозревателями; с API для неко­то­рых задач, типа созда­ния новых про­ек­тов и при­вязки их к GitHub-репозиториям, пока не разо­брался).

Впро­чем, настро­ить GitHub Actions ока­за­лось тоже не так про­сто (кажется, что скуд­ная доку­мен­та­ция и неста­биль­ное контр-интуитивное пове­де­ние суть не слу­чай­но­сти, но меры — свое­об­раз­ный фильтр — про­тив наплыва поль­зо­ва­те­лей при огра­ни­чен­ных ресур­сах самого GitHub’а :) ). Вна­чале я про­бо­вал раз­ме­щать исход­ные дан­ные (т.е., в основ­ном, *.md-файлы) в един­ствен­ной на тот момент ветви master, в кото­рую же и поме­ща­лись сге­не­ри­ро­ван­ные файлы. Это реше­ние выгля­дело непло­хим, но на деле выяс­ни­лось, что даже после успеш­ной сборки блога, сер­вер сра­ба­ты­вает неадек­ватно и при посе­ще­нии ассо­ци­и­ро­ван­ных web-адресов (в дан­ном слу­чае, http://circiter.github.io и http://circiter.tk) выдаётся http-ошибка 404, при­чем пове­де­ние сер­вера при ука­за­нии тех или иных кон­крет­ных стра­ниц меня­лось от опыта к опыту неким неси­сте­ма­тич­ным, непред­ска­зу­е­мым обра­зом. Вре­менно помо­гал трюк с кло­ни­ро­ва­нием репо­зи­то­рия и отправ­кой пустого набора изме­не­ний (команда git commit с клю­чем --allow-empty), но и это рабо­тало лишь изредка.

Поло­жи­тель­ные изме­не­ния про­изо­шли лишь после реор­га­ни­за­ции хра­ни­лища путем пере­не­се­ния исход­ных дан­ных в новую ветвь source. Раз­ме­щен­ные вне ветви master кон­фи­гу­ра­ци­он­ные файлы («workflows») меха­низма GitHub Actions ока­за­лись вполне рабо­то­спо­соб­ными, заодно изба­вив от необ­хо­ди­мо­сти при­ме­не­ния допол­ни­тель­ных ухищ­ре­ний, вроде уда­ле­ния дирек­то­рии .github перед ини­ци­и­ро­ван­ной кон­фи­гу­ра­ци­он­ным фай­лом GitHub Actions отправ­кой сге­не­ри­ро­ван­ных фай­лов в ветвь master (дан­ный трюк был исполь­зо­ван, — как позже выяс­ни­лось, зря, — во-избежание воз­мож­ных про­блем с рекур­сив­ным выпол­не­нием назна­чен­ных авто­ма­ти­че­ских дей­ствий).

Но даже после этого, оста­ва­лась одна про­блема с сер­вер­ным хра­не­нием акту­аль­ных вер­сий отда­ва­е­мых пользователям-посетителям сайта/блога дан­ных. Пред­по­ло­жи­тельно, сер­вер­ное кэши­ро­ва­ние при­во­дило к невоз­мож­но­сти неко­то­рое время уви­деть изме­не­ния в пуб­ли­ку­е­мых стра­ни­цах даже после их успеш­ной сборки. [Надёж­ный] спо­соб обхода мне не изве­стен, а может быть пока и не суще­ствует (кроме выше­упо­мя­ну­того хака с clone/commit/push, — именно его-то я и попы­тался при­ме­нить на этом блоге, впро­чем, без­успешно — авто­ма­ти­зи­ро­вать выпол­не­ние этой стран­ной опе­ра­ции с помо­щью сце­на­рия обо­лочки, выпол­ня­ю­ще­гося при сборке всего про­екта после опе­ра­ции git push origin source мне не уда­лось, не исклю­чено, что именно из-за суще­ство­ва­ния защиты от рекур­сии в GitHub Actions). Впро­чем, в какой-то момент, эта про­блема исчезла сама собой, без замет­ных при­чин…

Про­чие детали (оформ­ле­ние, пла­гины, etc)

Так­же, к репо­зи­то­рию, хра­ня­щему дан­ный блог, было под­клю­чено GitHub-приложение TeXify (но de-facto не было задей­ство­вано, в том числе по при­чине нали­чия на дан­ный момент неко­то­рых про­блем в гене­ри­ру­е­мых дан­ным при­ло­же­нием SVG-файлах) для под­держки фор­мул в Markdown-файлах, про­смат­ри­ва­е­мых в web-интерфейсе GitHub.

В каче­стве темы оформ­ле­ния сна­чала была выбрана тема Hacker, в неко­то­рой сте­пени из-за лицен­зии, но в основ­ном про­сто из-за внеш­него вида. Потом я при­ме­нил в каче­стве шаб­лона дру­гую гото­вую Jekyll-тему Hyde, так как Hacker с тем­ным фоном мало сов­ме­стима с печа­тью стра­ниц на бумаге, в част­но­сти и в осо­бен­но­сти при нали­чии на стра­ницах фор­мул (иначе бы их при­шлось визу­а­ли­зи­ро­вать два­жды – с чер­ным и с белым тек­стом) и тем-более диа­грамм с цвет­ными эле­мен­тами на про­зрач­ном фоне. Есте­ственно, при­шлось вне­сти доста­точно много мел­ких изме­не­ний в файлы темы оформ­ле­ния, в част­но­сти испра­вить пове­де­ние кар­ти­нок (в исход­ных кас­кад­ных таб­ли­цах тво­ри­лось нечто мало сов­ме­сти­мое с внут­ри­строч­ными картинками-фор­мулами). (Для инте­ре­су­ю­щихся всё-таки темой оформ­ле­ния Hacker, до-кучи при­веду ссылку на про­из­вод­ную тему hacker-blog.)

Так как я не исполь­зую чёт­кую при­вязку сооб­ще­ний к датам, то я не стал исполь­зо­вать ката­лог _posts, а создал свой (_blog_posts) и внес его в спи­сок кол­лек­ций в кон­фи­гу­ра­ци­он­ном файле _config.yml. Но на поверх­ность всплыли про­блемы сов­ме­сти­мо­сти меха­низма Jekyll-коллекций с мет­ками и кате­го­ри­ями — если для обыч­ных постов из папки _posts свойства-поля (доступ­ные в ruby-плагинах и liquid-разметке) site.tags и site.categories запол­ня­ются всеми име­ю­щи­мися, соот­вет­ственно мет­ками и кате­го­ри­ями авто­ма­ти­че­ски, то при исполь­зо­ва­нии кол­лек­ций эти свой­ства ока­за­лись пусты, что при­вело к необ­хо­ди­мо­сти правки и адап­та­ции извест­ных реше­ний по работе с мет­ками (типа liquid-кода или пла­ги­нов для отоб­ра­же­ния облака меток). В част­но­сти, для гене­ра­ции облака меток был при­ме­нен, с неко­то­рыми изме­не­ни­ями, пла­гин jekyll.tag-cloud.rb, а для гене­ра­ции стра­ниц, свя­зан­ных с мет­ками и пере­чис­ля­ю­щих соот­вет­ству­ю­щие посты – доста­точно про­стой кусок ruby-кода, сохра­нен­ный в файл-плагин tags.rb.

Пла­гин font-awesome.rb, оче­видно, не нуж­да­ется в ком­мен­та­риях. Хотя кроме этого набора знач­ков («ико­нок») я при­ме­нил (с помо­щью файла _sass/svg-icons.scss из репо­зи­то­рия jekyll-now) набор Free-Social-Icons.

В про­цессе напол­не­ния днев­ника слу­чайно обна­ру­жил, что kramdown даже при вклю­чен­ной под­держке GFM (вари­анта Markdown, исполь­зу­ю­ще­гося на GitHub Pages по-умолчанию, а так­же при отоб­ра­же­нии Markdown-файлов в web-интерфейсе для обзора репо­зи­то­риев и свя­зан­ных ресур­сов, типа wiki, сред­ства инфор­ми­ро­ва­ния об ошиб­ках, etc.) не счи­тает web-ссылки, не окру­жен­ные угло­выми «скоб­ка­ми» <...>, соб­ственно ссыл­ками, и не гене­ри­рует соот­вет­ству­ю­щую раз­метку (т.е. не под­све­чи­вает их). Однако, и здесь сразу же нашелся малень­кий пла­гин (потре­бо­вав­ший мини­маль­ной моди­фи­ка­ции), решив­ший эту про­блему (kramdown_easy_link.rb). Когда я пере­шёл к исполь­зо­ва­нию redcarpet, а потом commonmark, пла­гин пере­стал исполь­зо­ваться и был уда­лен.

До сих пор сохра­ня­ются про­блемы с [авто­ма­ти­че­ской] рас­ста­нов­кой пере­но­сов в сло­вах. Сей­час для рас­ста­новки пере­но­сов слу­жит неболь­шой само­пис­ный пла­гин hyphenate.rb, явля­ю­щийся обёрт­кой над биб­лио­те­кой Text::Hyphen. Воз­можно, стоит всё оста­вить как есть, пере­носы всё-таки рабо­тают.

Для работы с мет­ками и обла­ками меток исполь­зу­ются пла­гины jekyll.tag-cloud.rb и tags.rb для созда­ния, соот­вет­ственно, облака меток и свя­зан­ных с мет­ками стра­ниц, содер­жа­щих списки ссы­лок на сооб­ще­ния с этими мет­ками.

(В Gemfile и _config.yml так­же можно обра­ру­жить под­клю­чен­ными пла­гины jekyll-feed, jekyll-scholar, jekyll-sitemap, jekyll-titles-from-headings, jekyll_inline_highlight, jekyll-toc, jekyll-commonmark-ghpages.)

Пла­гин jekyll-scholar исполь­зу­ется для верстки биб­лио­гра­фи­че­ских спис­ков и внут­ри­тек­сто­вых ссы­лок на них (пока я только начи­наю исполь­зо­вать этот пла­гин, посте­пенно адап­ти­руя име­ю­щи­еся блог-посты); этот пла­гин исполь­зует обыч­ные *.bib-файлы (для ) в каче­стве базы дан­ных биб­лио­гра­фи­че­ских запи­сей, но для опи­са­ния сти­лей оформ­ле­ния запи­сей и ссы­лок исполь­зу­ются не *.bst, а *.csl-файлы. На дан­ный момент почему-то не вер­ста­ются гиперс­сылки в списке лите­ра­туры, но опция bibliography_template таки поз­во­лила инъ­е­ци­ро­вать необ­хо­ди­мый html-код в обход сти­ле­вого файла, так что такое поло­же­ние дел можно счи­тать при­ем­ле­мым ком­про­мис­сом.

Для нуме­ра­ции объ­ек­тов (тео­рем, рисун­ков, etc.) был напи­сан [очень про­стой] пла­гин numbered-labels.rb; пока он не годится для нуме­ра­ции фор­мул, набран­ных в liquid-окружении {% raw %}. При вклю­че­нии режима shared_context: true в группе опций simplemath: в кон­фи­гу­ра­ци­он­ном файле _config.yml, можно попы­таться поль­зо­ваться штат­ными сред­ствами ’а для авто­ма­ти­че­ской нуме­ра­ции фор­мул; это реко­мен­ду­е­мый спо­соб, но он пока неста­би­лен (а по-умолчанию всё-равно отклю­чен). N.B., пла­гин numbered-labels.rb обра­ба­ты­вает исход­ный доку­мент только один раз, повтор­ный про­ход раз­бора не тре­бу­ется, и, тем не менее, ссылки могут ука­зы­вать на объ­екты, опре­делён­ные как выше, так и ниже по тек­сту (в [бли­жай­шем] буду­щем, воз­можно, будет добав­лена под­держка гиперс­сы­лок для быст­рого пере­хода внутри доку­мента).

Для визу­аль­ного выде­ле­ния бло­ков с утвер­жде­ни­ями (лемм, тео­рем и т.д.) исполь­зу­ется «псев­до­окру­же­ние» (на самом деле это пара liquid-тегов) {% sentence_begin %} ... {% sentence_end %}. Содер­жи­мое этого псев­до­окру­же­ния про­сто обо­ра­чи­ва­ется в html-тег <div> с css-классом sentence-block.

Кстати, хотя это и не отно­сится к нуме­ра­ции объ­ек­тов, но раз уж зашла речь о пла­ги­нах, опре­де­ля­ю­щих новые теги, то стоит здесь упо­мя­нуть и об окру­же­нии {% abstract %} ... {% endabstract %}, кото­рое может быть исполь­зо­вано вме­сто свой­ства abstract:, ука­зы­ва­е­мого в yaml-заголовке и содер­жа­щего анно­та­цию к сооб­ще­нию днев­ника. В отли­чии от yaml-свойства, окру­же­ние abstract поме­ща­ется прямо в markdown-сообщение (прак­ти­че­ски в любом месте; можно в начале, сразу после yaml-заголовка) и поз­во­ляет при верстке анно­та­ции задей­ство­вать те же самые воз­мож­но­сти, что и при верстке основ­ного сооб­ще­ния; в част­но­сти, это поз­во­ляет вклю­чать фор­мулы в анно­та­цию (фор­мулы из yaml-заголовка, к сожа­ле­нию, не вер­ста­ют­ся; в т.ч. пока не полу­ча­ется вклю­чать фор­мулы в назва­ния сооб­ще­ний).

Фор­мулы

Для под­держки фор­мул при­шлось напи­сать отдель­ный про­стой пла­гин (simplemath.rb), про­из­во­дя­щий верстку исход­ного кода фор­мул с помо­щью пол­но­цен­ного -движка (из TeXLive) с после­ду­ю­щей кон­вер­та­цией *.dvi-файлов либо сна­чала (с помо­щью dvips) в [encapsulated] PostScript, а потом (с помо­щью ImageMagick convert) в PNG, либо сразу из *.dvi в *.png с помо­щью dvipng. Из-за про­блем с отоб­ра­же­нием фор­мул на схе­мах, нари­со­ван­ных с помо­щью пакета circuitikz, в насто­я­щий момент, при­ме­нены про­ме­жу­точ­ная верстка с помо­щью pdflatex и после­ду­ю­щее пре­об­ра­зо­ва­ние из *.pdf в *.png (но тоже с помо­щью ути­литы convert). При этом фор­мулы пред­ва­ри­тельно обо­ра­чи­ва­ются в необ­хо­ди­мый -код, кото­рый в слу­чае внут­ри­строч­ных фор­мул, среди про­чего, содер­жит команды записи неко­то­рых пара­мет­ров фор­мулы (а именно её типо­граф­ской «глу­би­ны» и высоты в пунк­тах) во внеш­ний файл, содер­жи­мое кото­рого, вме­сте с сооб­ща­е­мой коман­дой identify (тоже от ImageMagick) фак­ти­че­ской высо­той изоб­ра­же­ния в пик­се­лях, исполь­зу­ется для более кор­рект­ного пози­ци­о­ни­ро­ва­ния гото­вых кар­ти­нок на html-странице (хотя до сих пор с такой кор­рек­цией что-то не так – неко­то­рые фор­мулы отоб­ра­жа­ются слиш­ком низко отно­си­тельно базо­вой линии окру­жа­ю­щего тек­ста).

Реа­ли­зо­ван (но пока тести­ру­ется) режим верстки фор­мул в общем кон­тек­сте – если пара­метр shared_context равен false, то каж­дая фор­мула обо­ра­чи­ва­ется в отдель­ный .tex-файл, но при вклю­че­нии режима shared_context: true, все фор­мулы одного .md-файла соби­ра­ются в еди­ный файл .tex. Это, правда, влечёт за собой неко­то­рые неже­ла­тель­ные побоч­ные эффекты (по край­ней мере сей­час), вроде недо­ступ­но­сти кэши­ро­ва­ния уже свер­стан­ных фор­мул или необ­хо­ди­мость в дву- и даже трёх­про­ход­ной обра­ботке исход­ного тек­ста, но зато поз­во­ляет обра­щаться с фор­мулами в markdown-файле так же как и с фор­мулами в обыч­ном доку­менте , в част­но­сти, как уже было заме­чено выше, нуме­ро­вать их авто­ма­ти­че­ски. Осо­бых пре­иму­ществ режим shared_context: true не имеет: напри­мер, для раз­ре­ше­ния ссы­лок тре­бу­ется запус­кать -движок два­жды или три­жды, в то время как для режима shared_context: false доста­точно одного про­хода (но зато аж для всех фор­мул… тер­ри­то­рия ком­про­мис­сов ука­зы­вает на опти­маль­ность реше­ния, ино­гда :) ).

Оста­лось заме­тить, что пока, по тех­ни­че­ским при­чи­нам, \def-макроопределения, сде­лан­ные в одном -блоке, напри­мер в фор­муле, не видны в дру­гом, поэтому реко­мен­ду­ется, при необ­хо­ди­мо­сти, исполь­зо­вать команду \gdef.

Режим fisher_rule: true нуме­рует все выклю­чен­ные (т.е. не явля­ю­щи­еся внут­ри­строч­ными) фор­мулы (имеет смысл только если shared_context: true и simple_numbering: true). Этот режим (пра­вило Фишера) поз­во­ляет сэко­но­мить на одном лиш­нем про­ходе верстки, а так­же упро­стить ука­за­ние на фор­мулы в вашем тек­сте дру­гими людь­ми (или дру­гими [разум­ными] аген­тами :) ) даже если вы сами на эти фор­мулы не ссы­ла­лись. (Я пока не тести­ро­вал этот режим и не знаю, рабо­тает ли он.)

Кон­тей­неры

И хотя опыт­ный дра­ма­тург уже смог бы на основе преды­ду­щего раз­дела напи­сать сце­на­рий к фильму ужа­сов, тем не менее это не конец исто­рии. Ведь опи­сан­ный кон­вейер рабо­тает в Docker-контейнере! Т.е., инструк­ции из workflows-файла частично выпол­ня­ются на ubuntu linux, кло­ни­ру­ется репо­зи­то­рий, затем ска­чи­ва­ется и ини­ци­а­ли­зи­ру­ется Docker-контейнер на основе Alpine linux, уже в нем выпол­ня­ется скрипт build.sh, ска­чи­ва­ю­щий и уста­нав­ли­ва­ю­щий немало вещей, вклю­чая отно­си­тельно теже­ло­вес­ные ruby, bundler, jekyll, bash, git, imagemagick и т.д. После этого про­ис­хо­дит сборка блога, верстка и кон­вер­та­ция всех фор­мул, с после­ду­ю­щей отправ­кой всех сге­не­ри­ро­ван­ных фай­лов в ветвь master репо­зи­то­рия этого блога.

Гото­вый Docker-кон­тей­нер, вклю­ча­ю­щий именно нуж­ную ком­би­на­цию ПО, найти не уда­лось; и хотя пра­виль­нее было бы сде­лать новый кон­тей­нер, я пока обо­шёлся таким спо­со­бом (вна­чале про­сто не пред­по­ла­гая, как далеко всё зай­дет). Теперь для опти­ми­за­ции всего этого опре­де­ленно тре­бу­ется хотя-бы настро­ить кэши­ро­ва­ние (есте­ствен­ным кор­ре­ля­том эффек­тив­но­сти кото­рого может быть время сборки блога, изме­рен­ное от момента отправки исход­ных дан­ных в ветвь source до появ­ле­ния ожи­да­е­мых изме­не­ний на глав­ной странице)…

Вор­ча­ние

Пред­по­ла­га­е­мые про­цес­сор­ные и сете­вые затраты выгля­дят несо­раз­мер­ными с реша­е­мой зада­чей, но ведь мно­гие интернет-ресурсы, вклю­чая неко­то­рые круп­ные форумы, давно исполь­зуют вер­ста­е­мые на сто­роне сер­вера фор­мулы, и не исклю­чено, что с мень­шими наклад­ными рас­хо­да­ми; эта воз­мож­ность должна стать прак­ти­че­ски обще­при­ня­той. (К сожа­ле­нию, по-факту, очень часто, слиш­ком часто при­хо­дится стал­ки­ваться с кли­ент­ским рен­де­рин­гом на основе какого-нибудь MathJax’а.)

Аль­тер­на­тивы

Трудно не согла­ситься, что опи­сан­ный кон­вейер выгля­дит избы­точ­ным, но более про­стые реше­ния вроде mimeTeX ока­за­лись слиш­ком огра­ни­чен­ными. Впро­чем, можно ещё попро­бо­вать встро­ен­ный в GitHub, но плохо доку­мен­ти­ро­ван­ный API-механизм (http://render.githubusercontent.com/render/math?math=<url_encoded_formula>) рен­де­ринга фор­мул. Странно, что эта воз­мож­ность за все время сво­его суще­ство­ва­ния не стала стан­дарт­ным спо­со­бом отоб­ра­же­ния фор­мул. (Воз­можно, я бы и сам вос­поль­зо­вался именно этим спо­со­бом, если бы была воз­мож­ность извлечь базо­вую линию, т.е. глу­бину, из про­ду­ци­ру­е­мых изоб­ра­же­ний.)

Суще­ствует конечно и Google Chart, неплохо доку­мен­ти­ро­ван­ное сред­ство визу­а­ли­за­ции диа­грамм, гра­фи­ков и фор­мул; а так­же много дру­гих похо­жих русур­сов. Но все с теми же недо­стат­ками и без эффек­тив­ной инте­гра­ции с GitHub.

Даже для рабо­та­ю­щего в kramdown (реа­ли­за­ции markdown, ранее исполь­зо­вав­шейся в моем днев­нике, но впо­след­ствии заменён­ной на commonmark) MathJax-плагина есть ком­про­мисс­ное реше­ние с пред­ком­пи­ля­цией фор­мул (резуль­тат, впро­чем, опять неудо­вле­тво­ри­те­лен – кли­ент­ские JavaScript-сценарии не нужны, но тре­бу­ются css-стили и под­гру­жа­е­мые шрифты, а свер­стан­ные фор­мулы явля­ются кус­ками тек­ста, а не изоб­ра­же­ни­ями).

Для пол­ноты кар­тины стоит упо­мя­нуть, что уже по сво­ему опре­де­ле­нию, раз­ме­ще­ние ста­тич­ного блога не обя­за­тельно тре­бует выпол­не­ния кода на сто­роне сер­вера и гене­ра­ция может осу­ществ­ляться на машине пуб­ли­ку­ю­щего. В этом слу­чае я лично не вижу осо­бых при­чин в исполь­зо­ва­нии Jekyll+ruby, — мне бы хва­тило и какого-нибудь bashblog’a, моди­фи­ци­ро­ван­ного для под­держки фор­мул, или кон­вер­то­ров типа htlatex или pandoc+GladTeX, поз­во­ля­ю­щих кон­вер­ти­ро­вать -исходники (*.tex) в *.html-файлы.

Инте­рес­ной пред­став­ля­ется идея исполь­зо­ва­ния упо­мя­ну­тых генераторов/конвертеров (bashblog, pandoc+GladTeX) и на сто­роне сер­вера, в ком­би­на­ции с GitHub Actions. Осо­бых пре­иму­ществ перед Jekyll, конечно, нет; разве что bashblog будет заве­домо менее гро­мозд­ким реше­нием чем Jekyll.

Ещё вор­ча­ние

Но GitHub предо­став­ляет уни­каль­ную воз­мож­ность, или, по край­ней мере, более или менее удачно реа­ли­зует довольно уни­каль­ную идею под­держки Jekyll для сопро­вож­де­ния git-репозиториев. Вполне зако­но­мерно, что этой ком­би­на­цией воз­мож­но­стей, и в осо­бен­но­сти после внед­ре­ния GitHub Actions, мно­гие стре­мятся вос­поль­зо­ваться. Раз­ра­бот­чики GitHub уже про­во­дили неболь­шой опрос среди поль­зо­ва­те­лей, пред­ла­гая запол­нить анкету с ука­за­ниев потен­ци­аль­ных про­блем меха­низма Actions. Я, отве­чая на вопросы анкеты (в коли­че­стве двух штук, если не счи­тать допол­ни­тель­ное поле для жалоб и пред­ло­же­ний в сво­бод­ной форме), ука­зал на недо­ста­точ­ность доку­мен­та­ции и неко­то­рые слож­но­сти с отлад­кой кода, рабо­та­ю­щего в рам­ках этого меха­низма (рефе­ренс­ным «иде­а­лом» для меня вообще явля­ется баналь­ный ssh-протокол); инте­ресно было бы узнать общую ста­ти­стику по резуль­та­там этого опро­са…

Заклю­че­ние

С целью предъ­яв­ле­ния чита­телю отно­си­тельно счаст­ли­вой кон­цовки, спешу упо­мя­нуть, что блог всё-таки зара­бо­тал, с при­мерно сотого «commit»’а.

Ссылки

• GitHub Pages
• Markdown
• Jekyll
• Jekyll @ GitHub
• Hyde
• Hyde @ GitHub
• Hacker @ GitHub
• hacker-blog @ GitHub
• GitHub Actions
• mimeTeX
• TeXify