Doomed to Wordpress (circa 1993)

2020/09/22 keyserver

Устаревание или отсутствие ключей — постоянная проблема для человека, работающего на старых дистрибутивах.

W: There is no public key available for the following key IDs:
648ACFD622F3D138
E: Release file for http://archive.debian.org/debian/dists/jessie-backports/InRelease is expired (invalid since 580d 3h 3min 36s). Updates for this repository will not be applied.

Можно конечно просто игнорить все эти предупреждения, но пока есть возможность сделать всё как положено, можно сделать так:

apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 648ACFD622F3D138

echo 'Acquire::Check-Valid-Until no;' > /etc/apt/apt.conf.d/99no-check-valid-until

#apt #debian


[] permanent link

2020/09/21 local infile

По умолчанию в MySQL не включена возможность LOAD DATA LOCAL INFILE на удалённый сервер. Запускать клиент нужно с ключом --local-infile:

mysql -u user -p --local-infile -h host dbname

После этого данные загружаются так:

load data local infile '/path/to/local/file.csv' \
into table table_name character set utf8 FIELDS \
TERMINATED BY ','  ENCLOSED BY '"' LINES \
TERMINATED BY '\n' (field, names, list);

#mysql


[
] permanent link

2020/09/21 apt

Создание собственного репозитория apt

Много (хотя на самом-то деле не так уж и много...) разных решений предлагалось из-за нелепого перехода Debian на systemd. Странно, что нигде, кажется, не предлагалось такого варианта, как остаться на всю жизнь на Wheezy (как последней версии без принудительного systemd) и бэкпортить туда всё необходимое. Теоретически это должно быть осуществимо, если не быть совсем параноиком по безопасности.

Мне, честно говоря, больше нравится Squeeze, и вообще почему-то чётные релизы Дебиана всегда более стабильные, чем нечётные, которые зачастую непонятно вообще зачем выпущены — версии интересующих меня программ там зачастую не меняются, зато ломается что-то непременно. Так и в Wheezy, кажется, что-то было капитально сломано (CUPS? не помню точно). Тем не менее, бэкпортировать что-либо на Squeeze было, насколько я помню, сложно из-за необходимости выпиливать multiarch отовсюду. Поэтому ничего не остаётся, как попробовать остаться на Wheezy навечно.

Ещё меня всегда удивляло, почему в стандартных репозиториях доступна только одна версия каждой программы. Мне всегда казалось естественным иметь возможность установить произвольную версию из числа нескольких.

Процедуру бэкпортирования надо будет описать позже, сейчас же будет пример выкладывания уже готовых пакетов в собственный репозиторий. Есть такой проект ubuntuzilla, который готовит deb-пакеты из официальных сборок программ Мозиллы. Как показал опыт, они работают независимо от дистрибутива и его версии. Поэтому заморачиваться со структурой каталогов для каждой версии не нужно. Конфиг их репозитория для apt:

deb http://downloads.sourceforge.net/project/ubuntuzilla/mozilla/apt all main

Я так и не понял, как скачать весь репозиторий с sourceforge, поэтому вручную скачал только нужные мне (проверенные) версии. Сохраняю их в ~/src/ubuntuzilla. Далее:

cd ~/src/ubuntuzilla
dpkg-scanpackages -m . | gzip -9c > Packages.gz

Ключ -m как раз должен добавлять в индекс все обнаруженные версии (хотя не проверял, что̀ будет без него).

После этого выкладываю каталог ubuntuzilla на свой сервер. Строка для apt выглядит так:

deb http://home.rp.spb.su/ubuntuzilla/ ./

#apt #dpkg-scanpackages


[] permanent link

2020/08/26 perl curse

Случайно наткнулся на ещё одну реализацию ООП для Perl:

https://github.com/Ovid/Cor/wiki

То есть ещё одна альтернатива Moose. Есть хорошие идеи, но название крайне неудачное и нет типизации даже в той мере, как она есть в Moose (отложено на будущее), а как я уже писал ранее, мне и Moose-то хочется использовать не в последнюю очередь из-за этих зародышей типизации.

И в обоснование необходимости такой реализации ООП приводится вот эта статья:

http://winestockwebdesign.com/Essays/Lisp_Curse.html

Очень примечательная. Действительно, то, что̀ там сказано о Лиспе, столь же может быть отнесено и к Perl. Невероятная мощь языка превращает программирование на нём в самодостаточный процесс, приносящий удовольствие, и в то же время позволяет легко реализовать то, чего в языке, как может показаться, не хватает. Поэтому программисты плодят многочисленные собственные реализации одного и того же, остающиеся неизвестными и не превращающиеся в стандарт. Это объясняет и ситуацию с веб-фреймворками и CMS, на которую я ранее многократно жаловался. Я и сам формулировал это для себя таким образом, что перл-программист не хочет использовать готовые решения, хочет всё писать с нуля и сам, потому что он отчасти делает это из-за чистого удовольствия низкоуровневой работы с языком. То есть он работает как художник, а не как практик. Теперь, однако, сюда можно добавить ещё и такой фактор, как объективная мощь языка.

Я, однако, не могу сказать, что мне легко написать CMS с нуля. И не думаю, что на Лиспе было бы проще, если бы я вполне знал Лисп. CMS отражает иной если не уровень, то стиль мышления, мышление пользователя, а не разработчика. Ранее я тоже об этом писал, о том, какое страдание для программиста-художника работать с запросами конечных пользователей. В этом плане, возможно, конечных пользователей лисп-продуктов не так уж и много и уровень их пользовательского опыта, возможно, иной. А пользователей веба миллиарды и уровень их крайне низок.


[] permanent link

2020/08/20 alive

Недостаток существующих систем веб-поиска — они ориентированы на сайты или страницы, а не документы. Цель современной поисковой системы как будто бы отразить современное состояние веба, хотя понятно, что это состояние является случайным. Сайты и страницы возникают и исчезают, зачастую по самым случайным причинам: нету денег на хостинг, сайт пропал, через несколько дней — исчез из поисковой выдачи, хотя бы там и была уникальная информация. Какие-то авторы сайтов умирают или по каким-то причинам меняют свои занятия; если сайт находится на платном хостинге, вскоре он бесследно исчезнет. Одни сайты копируют информацию с других сайтов, всё дублируется сотни раз, одни и те же тексты и новости, но с точки зрения поисковиков всё это — разный контент! Который отображается отдельными пунктами в поисковой выдаче, хотя ни для кого не нужны одновременно все эти дублирующиеся тексты — а поисковик не в состоянии определить, какой из них является исходным или лучшим.

В моей поисковой системе будут индексироваться не страницы, а документы. И в метаданных документа будет поле alive. Успешно проиндексированный документ помечается как alive. При повторных индексациях, если документ исчез, флаг alive снимается, но контент у меня локально сохранён и доступен теперь непосредственно с серверов поисковой системы. Документы не должны исчезать бесследно.

В общем-то, нечно подобное и даже более универсальное (с разными версиями страницы, доступными одновременно) предлагает archive.org, но его интерфейс всё же на заточен под поиск.


[
] permanent link

2020/07/26 emacs cms

Как-то я придумал идею EmacsCMS, то есть управления сайтом из Emacs. Оказывается, подобное уже есть: https://github.com/kofuk/emacs-cms. Но, похоже, всё-таки не то. Там Emacs сам выступает в качестве сервера приложений, что̀, конечно, совершенно непрактично. Я же имел в виду, что Emacs будет предоставлять нечто вроде интерфейса для редактирования к виртуальному иерархическому дереву объектов, типа как в Zope.


[] permanent link

2020/06/30 handel

Вот такое ещё есть (было?):

Building E-Commerce Sites with Handel https://www.perl.com/pub/2005/11/17/handel.html/ https://metacpan.org/pod/Handel

Выглядит обещающе, но последний релиз 2011 года. Остаётся надеяться, что Catalyst достаточно консервативен.

Вообще это было бы крайне удобно, если бы функционал интернет-магазина можно было бы добавлять к существующему сайту в виде набора модулей (в данном случае это должен быть сайт на Catalyst, но я имею в виду сайт на чём угодно — хоть на самописных CGI-скриптах). Да и не только магазина. По сути, все эти магазины, форумы, лайки и прочее — всё это совершенно стандартно и однообразно. Всё сводится к определённой структуре БД и интерфейсу к ней на определённом языке программирования. И ничто не мешало бы создать универсальные модули типа Web::Shop, Web::Forum, Web::Likes, содержащие такой интерфейс и не привязанные к конкретному движку/фреймворку (который может добавлять свою дополнительную прослойку). В гофере такие вещи вообще могли бы делаться на уровне интерфейса клиента (как отдельные item types, например) или через внешние скрипты, подходящие для любого сервера, настолько они все (форумы, магазины и проч.) одинаковы.

#perl #e-commerce

UPD: Markdown настолько идиотский формат, что не позволяет даже нормально хэштеги вставить. Приходится отбивать начальный # пробелами. Позже напишу отдельный пост о формате разметки для текстовых файлов.


[] permanent link

2020/06/07 perl cms

Неожиданно почти решились мои проблемы с поиском CMS на Perl, по крайней мере для моих текущих целей. Во-первых, нашёл вот такую вещь:

https://metacpan.org/pod/Yancy

Это CMS на Mojolicious (который, кстати, при всё более близком рассмотрении оказывается всё лучше), пока что work in progress, но прогресс действительно есть (нашёл и зарепортил баг, его разработчик его пофиксил через пару дней и выпустил новый релиз), удобный и красивый дизайн, и главное — то, что̀ я как раз искал, возможность подключения к произвольным базам и генерация удобного и работающего CRUD для них, даже с поддержкой связей таблиц по внешним ключам, на что̀ я и надеяться уже перестал. Кроме БД, впрочем, пока что почти ничего нет, но мне и нужна была в первую очередь БД.

Во-вторых, я наконец почти разобрался, как пользоваться CiderCMS (и оно всё же оказалось готовым и годным продуктом, а не сырым, как я думал ранее).

В-третьих, я попробовал RapidApp, о котором писа́л ранее. Вовсе не так уж он похож на Битрикс, скорее разве что по интерфейсу, чем по идее. Он может всё то же самое: подключаться к произвольной БД и создавать удобный табличный интерфейс для редактирования записей. Есть также пара готовых приложений на его базе: Rapi::Blog (движок блога c приличным дизайном и (почти?) стандартным для блога функционалом), Rapi::Fs (просмотрщик файловой системы).

Правда, он довольно громоздкий: Catalyst, DBIx::Class, ExtJS, с базами из Вордпресса и других CMS, которые я за неимением иного ему скормил, процесс сервера занял >132 Мб (процесс rdbic.pl, который не включает только CRUD для базы, почему-то ещё больше: >160 Мб). В продакшене как движок сайта я не стал бы использовать (разве что Rapi::Blog, если бы пришлось делать полноценный блог под заказ), а как админский интерфейс для просмотра баз и файлов, особенно не моих — пока что лучший найденный вариант. (Yancy лучше во многих отношениях, но любой сторонний пользователь сразу ощутит отсутствие привычных удобств, то есть потребует доработки и допиливания, если им кто-то будет пользоваться, кроме меня.)

Так что единственное, что̀ ещё осталось для моих рабочих целей, это нормальный интернет-магазин на Perl. Нашёл ещё вот такое:

https://agoracart.com/demos.php

(Да, сайт на php, что̀ уже само по себе настораживает.) Это какая-то дремучая архаика на cgi-скриптах. Похоже, этот продукт претендует на ту же нишу, что и многочисленные поделия на php, то есть установку на шаред-хостингах. То есть как бы получается, что в наши дни CGI на Perl — это аналог mod_php под apache, такой же простой, дешёвый, непроизводительный и архаичный. (Хотя, судя по приводимому на сайте количеству инсталляций последней версии — менее 100, конкурирует с php без особого успеха.) Код даже без use strict, с local внутри функций вместо my и прочими призраками из начала 90-х (удивительно, что апострофа нет в качестве разделителя имён пакетов и что используется CGI::Simple, а не CGI). С другой стороны, должен признать, что такой архаичный код часто выглядит более понятным, чем современный с use strict и прочим, зато с миллионом уровней абстракции. К недостаткам отнесём также собственный шаблонизатор и при этом зависимость от модных современных JS-библиотек. Кроме того, практикуется расширение функционала в виде платных модулей.

Но вообще-то, если оно работает, а заказчику не объяснить, что такое PSGI, фрэймворк и сервер приложений, то почему нет?


[] permanent link

2020/06/01 static typing

Вот любопытная статья:

https://codefork.com/blog/index.php/2016/09/24/the-myth-of-artisanal-programming/

и особенно цитата: "it’s no mystery why people are turning to the newer generation of statically typed languages like Scala, Haskell, Go, etc."

Как работает кое-что из этого новомодного софта на Хаскелле, я имел несчастие видеть. Такое ощущение, что его действительно выбирают как язык ради языка, не заботясь совершенно о том, выполняет ли написанная программа то, что̀ от неё изначально требуется.

Но интересно и другое: я в последнее время подсел на Moose не из любви к ООП, а именно из-за того, что тот добавляет к перлу хоть какую-то типизацию (хотя бы на уровне свойств объектов), которой мне ощутимо не хватает. И мне всё чаще хочется пользоваться Method::Signatures::Simple, потому что объявлений параметров функций тоже не хватает. И я уже задумывался над тем, что и какой-то модуль для явной типизации остальных переменных тоже неплохо бы освоить. И хорошо, что перл всё это позволяет своими средствами и без смены языка.

Потому что воистину зачастую половина работы в скриптовых языках (с php то же самое) заключается в ручном написании проверок переданных параметров и типов переменных.


[] permanent link

2020/05/30 craft programming

Публикую здесь по-русски некоторые идеи и обоснования идей крафтового программирования, которые размещены по-английски на сайте моего грядущего поисковика http://legeon.org.

Вы можете себе представить, чтобы каждый год, например, выходила навая версия ПДД? Постоянные изменения в конституции и прочие нововводимые законы уже давно бесят всех порядочных людей. Можем ли мы представить, чтобы в русском или любом ином языке по нескольку раз в год менялись правила орфографии? А тем не менее подобное происходит в современном мире языков программирования и интернет-технологий. Всё это делается обычно под предлогом заботы о безопасности (но иногда и без всякого предлога, напоминая тот же самый "взбесившийся принтер"). Понравилось бы кому, если б его 10 раз в год заставляли менять машину или квартиру из-за обнаруженных в них опасностей и уязвимостей?

(Далее следует обоснование выбора Perl в качестве основного языка разработки и Z39.50 в качестве протокола поискового сервера.)

Поддержка Z39.50 нужна для стандартизации взаимодействия с поисковым сервером. Фактически нужны два стандарта: поискового запроса, вводимого пользователем, и запроса, отправляемого бэкенду. Насколько мне известно, первый, несмотря на некоторые попытки, не стандартизирован до сих пор. Для второго же, пожалуй, со времён Z39.50 ничего лучшего не придумано. Опять же, стандарты эти должны быть защищены от "развитий" и изменений, которые заставили бы меня провести весь остаток жизни в переделывании уже написанного и работающего кода.


[] permanent link

2020/05/28 noscript

Я пользуюсь браузером Seamonkey (как единственным графическим браузером, сохраняющим одинаковый интерфейс уже лет 15), и на одном из компов у меня в нём стоит плагин NoScript. До недавнего времени это было очень удобно, невероятно ускоряло загрузку и снижало нагрузку на CPU, теперь же кривых сайтов, не работающих без JS, всё больше, и приходится всё чаще включать скрипты с основного домена сайта, чтоб хоть что-то увидеть, и избирательно со сторонних доменов. И я прихожу в ужас от обилия этих никчёмных сторонних сервисов, которые стало модно пихать себе в сайты. В этом посте я буду записывать сведения о доменах разных скриптов, чтобы помнить, что̀ они делают и насколько надо их отключать. Зачастую даже изучив сайт того или иного скрипта, невозможно понять, что̀ он делает и зачем он вообще кому-то мог понадобиться. Джаваскриптовый психоз рано или поздно заставит меня полностью уйти в гофер.


[
] permanent link

2020/05/27 craft programming

Очень тяжело работать с пользователями. Как только подключаются мнения конечных пользователей, так программист вынужден под них подстраиваться, потому что они не могут подстроиться под него: программист когда-то сам был пользователем, а пользователь не был и, вероятно, не будет и не хочет быть программистом. Результат — вместо того, чтобы стремиться к самодостаточному коду, совершенному, как произведение искусства, программист, как ремесленник, угождает прихотям пользователя — как художник, который рисует рекламу, или кабацкий музыкант.

(под заглавием «Working with end users is hard» написано для обоснования идеи крафтового программирования)


[
] permanent link

2020/05/18 google spam

Уже пару месяцев слежу вот за этой любопытной статистикой:

https://www.spamhaus.org/statistics/networks/

Самое отвратительное то, что как раз именно из-за идиотской спам-политики этого самого Гугла стало почти совершенно невозможно пользоваться электронной почтой. Изначальная прекрасная идея электронной почты как сети многочисленных мелких почтовых сервисов, приблизительно копирующей устройство физической, бумажной почты, была фактически убита крупными провайдерами, и Гуглом в первую очередь. Я уже давно не могу нормально пользоваться ящиками, расположенными на моих личных серверах или на удобных мне серверах малоизвестных провайдеров именно из-за идиотских спам-фильтров Гугла и прочих, которые автоматом отправляют в спам всё, что̀ не пришло с их серверов или с серверов пары-тройки других почтовых гигантов.

По ссылке мы видим истинное лицо этих лицемерных борцов со спамом.


[] permanent link

2020/04/01 frameworks vs diy

Мне всегда казалось, что для программиста не должно быть проблемой что-то запрограммировать. По крайней мере, поиск готового стороннего решения я всегда считал уместным в том случае, если существует решение, в точности решающее задачу. Если оно решает её не в точности, то, выбрав путь готового решения, приходится либо переформулировать задачу, что̀ мне кажется неверным путём, потому что следует исходить из цели, а не из ограниченности инструментария (либо, значит, цель не столь важна — но сто́ит ли тогда ею и заниматься?), либо переделывать найденное «готовое» решение, что предполагает затраты времени и сил на обучение его внутренней архитектуре, без знания которой модификации будут дилетантскими и рискованными, затруднение поддержки в будущем (в случае, если новые версии готового решения окажутся несовместимы с изменениями и опять потребуется всё переделывать), да и просто архитектура готового решения может не предполагать вмешательств, в этом случае понадобится замена решения и затраты времени и сил на поиск и внедрение нового. В общем, мне всегда казалось, что проще написать всё самому, ибо, повторюсь, для программиста это не должно составлять проблемы, ибо он на то и программист, чтоб программировать, а не гуглить.

Целый день писал тесты для сайта на Poet/Mason. Сразу скажу, что эту архитектуру для данного сайта выбрал я давно, сознательно и пока что не было случая, чтобы мне приходилось горько об этом жалеть. Конечно, сама идея шаблонизатора как некоего дополнительного недоязыка, который приходится осваивать разработчику и который требует особого интерпретатора, дурна и её следует избегать. Масон несколько оправдывается, во-первых, чрезвычайно удобной идеей объектно-ориентированных шаблонов (что̀, впрочем, некоторые считают как раз его недостатком; при этом я не рассматриваю всё объектно-ориентированное как благо, но в данном случае это прекрасный пример уместности ООП), во-вторых, минимальностью самого синтаксиса шаблонов: по сути, есть только маркеры, указывающие, интерпретировать ли данный код как perl или html, а всё остальное можно и не использовать. (Я говорю о Mason 2; судя по масоновской рассылке, до сих пор многие сидят упорно на Mason 1; тот куда больше похож на классический шаблонизатор или php, и я не понимаю этих людей.)

Приходится иногда, однако, как сейчас, после потраченного дня сознавать всё же, что даже самый лучший сторонний фрэймворк не заменит собственного самописного.

Начинается всё с того, что мне надо для тестов переопределить пару параметров в конфиге. С удивлением обнаруживаю, что возможность вручную выставить значение ($conf->set(...)) не предусмотрена! И сознательно, т.к. это, дескать, дурной тон, менять конфиги где попало. "Setting and resetting of configuration values will make it much more difficult to read and debug code!" Да, разумеется, особенно с таким синтаксисом, который всё же предусмотрен — с оговоркой, что исключительно для тестирования — чтобы временно поменять значение для данной лексической области видимости:

my $lex = $conf->set_local({key => 'value', ...});

В моём случае это сработало. Но, учитывая, сколь разными могут быть ситуации тестирования и специфику областей видимости в perl, тем более в Moose, не удивлюсь, если будет работать не всегда (например, когда придётся разбить код данных тестов на несколько модулей/функций, а общий код, содержащий как раз эти изменения конфига, вынести отдельно). Надо ли говорить, что если бы фрэймфорк писал я, не было бы такого ограничения. Когда я работаю с чужим кодом, возможность оперативно изменить значение из конфига в любом месте кода и быстро увидеть результат, вместо того чтобы городить отдельные тестовые конфиги или создавать их в памяти, требуется постоянно. (А тут кстати даже и создать конфиг нельзя, не прибегая к файлу. Конфиг почему-то всегда считывается из файлов, причём имена файлов хардкодные! Конечно, я могу переопределить класс конфига и всё это там сделать. В будущем я так и сделаю. Но на выяснение неизбежности этого весь день и ушёл. Дело осложнялось тем, что ряд параметров ещё и устанавливается в значения по умолчанию в других местах и через конфиг не переопределяется, хотя неработающий пример приведён в документации, но это уже можно считать багом. А если бы речь шла не о тестах, а о чём-то более срочном и важном?)

Мало того! И масоновский компонент нельзя создать на лету, поскольку иного способа его создания, кроме чтения из файла, не предусмотрено! Приходится городить кучу временных файлов. К чему объектноориентированность шаблонов, если такой шаблон, представленный в программе объектом, нельзя создать как любой другой объект?

Некоторые объекты являются синглтонами, но нет возможности переинициализировать их либо работать в каждом тесте с заново создаваемым объектом. Использование синглтона само по себе тут оправдано, но возможность заменить/переинициализировать его для тестирования является очевидной необходимостью. (Допускаю, что в некоторых реализациях данного паттерна это технически или идеологически невозможно. Но в perl препятствий к этому я не вижу.)

Итог: день потрачен на то, чтобы выяснить, что ряд возможностей, которые мне понадобились, отсутствуют в выбранном мною фреймворке, не работают или работают странно. Написанный тест в результате изобилует некрасивыми хаками, призванными как-то выкрутиться в узких рамках, в которые поставили меня описанные ограничения.

Конкретно дело не в Poet. В другом фрэймворке это были бы, возможно, другие ограничения. Сколько кода собственного, полностью удовлетворяющего меня фрэймворка мог бы я написать за это время?


[
] permanent link

2020/03/30 fossil

http://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki

Так хорошо ругают git, что даже захотелось попробовать (fossil, в смысле, попробовать).


[] permanent link

2019/06/14 UR

Я обнаружил UR как возможную альтернативу KiokuDB, но на самом деле это скорее альтернатива Moose, ориентированная более на табличные объекты. Как известно, нормальный ORM для Moose мне пока так и не удалось найти.

https://metacpan.org/pod/UR


[] permanent link

2019/06/12 openinteract

Вот ещё пример абсолютно неизвестного, непризнанного и забытого, но, возможно, достойного приложения на перл:

https://metacpan.org/pod/distribution/OpenInteract/OpenInteract/Intro.pod

В редких упоминаниях в интернете рекомендуется сравнивать его с Zope. Как я понимаю, там тоже веб-интерфейс к собственной объектной БД. Но, опять же, это Apache/mod_perl. Сколько хорошего софта погублено и обречено на забвение из-за ориентации на эту оказавшуюся провальной платформу.


[] permanent link

2018/05/02 masonsql

Вот, похоже, серьёзный и используемый в бою фрэймворк (на Mason1, правда) — опять же никакой инфы нигде, кроме пары постов в рассылке Масона и пары объявлений о найме работников для портирования на Mason2.

https://www.leader.it/Portal/MasonSQL


[] permanent link

2018/04/27 interchange

Удивительно, но есть вполне рабочее решение для e-коммерции на Perl, существует с 1995 г., последний коммит 20 дней назад, никакой инфы — нигде! Нашёл совершенно случайно.

http://www.icdevgroup.org/i/dev/

Существенный недостаток, конечно — собственный шаблонизатор.


[] permanent link

2017/12/11 more perl cms

Начал сайт на ShinyCMS и вскоре увидел, что там нет такой элементарной вещи, как привязка постов блога к секциям. Технически заложена возможность нескольких блогов, но к ней ней интерфейса не то что в админке, а даже в коде толком нету (при создании поста в блоге id блога хардкодится).

Полез в инет и, изучая сайты, сделанные на оной ЦМС, наткнулся на удивительные вещи.

http://rperl.org/ — компилятор перл, якобы сопоставимый с C/C++/Fortran и, в отличие от множества подобных проектов, вроде бы даже продакшен-уровня. Та же компания собирается в 2018 выпускать rperl-enabled смартфон (http://www.autoparallel.com/products/genius/), так что всё серьёзно. Правда, сайт http://cloudforfree.org/, который должен предоставлять какие-то облачные сервисы с этим самым rperl, не работает, потому что перегружен.

Оттуда вышел на ещё разные проекты улучшения перла, правда, не столь амбициозные: http://perl11.org/

Помимо этого, обнаружились ещё несколько ЦМС:

http://wiki.cyclone3.org/index.php/Cyclone3Frameworkinstallation — какой-то невероятно амбициозный проект, не решусь опробовать; как я понимаю, состоит из серверной части под апачем (фрэймворк) и клиентской — внимание! — на XUL! При этом последние обновления совсем недавние и, похоже, активно развивается. Уже апач в 2017 г. странен, но только что похороненный Мозиллой XUL — это совсем за пределами разумения. Хотя я, конечно, за XUL. Демо не нашёл.

http://xims.info/about.html — нечто заброшенное в 2013 г. Вроде нормально выглядит и даже интерфейс напоминает Zope, но настолько древний код, что даже Seamonkey всё перекорёживает.

http://cms.simpleness.org/about/for_developers — меня настолько шокируют шрифты, что всерьёз не могу воспринимать. Демо выглядит как сырое поделие, ссылка здесь только для полноты картины.

https://www.dreamwidth.org/site/opensource — как я понял, форк ЖЖ. Поддерживается. https://github.com/dreamwidth/dw-free

Понемногу смирился с TT, при некоторой настройке (INTERPOLATE=1, OUTLINE_TAG, собственные TAGS) вполне можно пользоваться.


[] permanent link

2017/12/04 perl wiki

Twiki и Foswiki, насколько я понимаю, часто используются как CMS. На них поэтому также надо обратить внимание.

Сайты на Foswiki: http://foswiki.org/About/ExampleSites

У Twiki такой странички не нашёл.


[] permanent link

2017/11/30 HTML Zoom

Вот ещё интересный шиблонизатор:

http://search.cpan.org/~jjnapiork/HTML-Zoom-0.009009/lib/HTML/Zoom.pm

Синтаксис не очень, но идея хороша.

UPD (14.12.2017): Вообще много подобного есть. Достаточно посмотреть Catalyst::View::* на CPAN.


[] permanent link

2017/11/28 rapidapp

http://www.rapidapp.info/ — очень навороченный фреймворк на перле и js, настолько, что напоминает битрикс по интерфейсу. На Каталисте. Отмечу для себя, но лезть не буду.

Внимание! У них есть интерфейс для создания CRUD: https://metacpan.org/pod/rdbic.pl Есть и интерфейс к файловой системе. JS отпугивает, впрочем.


[] permanent link

2017/10/30 shinycms

Поставил ShinyCMS 0.9.1 так:

perl Makefile.PL
make

установит модули. Перед этим должны быть установлены Module::Install и Module::Install::Catalyst. (На сервере с FreeBSD после этого установилось не всё. Пришлось повторно запускать make. XML::Feed не поставился, доставил из портов. Оттуда же пришлось ставить не упомянутые в качестве зависимостей DBI и DBD::mysql.)

(UPD: проще cpanm -v --installdeps . Могут возникнуть проблемы с тестами для DBIx::Class::Schema::Loader. Это из-за бага в Hash::Merge, поэтому нужен Hash::Merge версии 0.200.)

Базу надо создать вручную:

mysql -u root
mysql> create database shinycms character set utf8 collate utf8_general_ci;

и далее создать юзера и заполнить таблицы тестовыми данными:

mysql -u root < docs/database/mysql-create-user.sql
./bin/database/build-with-demo-data

Важно! Базу нужно сразу создавать с кодировкой utf8, и в конфиге shinycms.conf внести следующие изменения для работы с юникодом:

encoding utf8

в начале,

mysql_enable_utf8 1

в разделе connect_info, а в разделе View::HTML:

ENCODING           utf-8

(вообще я конечно уже думаю, чем и как заменить этот ужасный TT).

Кроме того, для использования юникода в конфиге надо ещё добавить

-UTF8 => 1

в параметры драйвера конфига General в файле ShinyCMS.pm (строка 44). Иначе, например, название сайта в конфиге будет не написать кириллицей.

Запускаем:

./script/shinycms_server.pl

Админка:

http://localhost:3000/admin/ (admin:changeme)

Любопытно, что здесь также используется принцип построения страницы из "кирпичиков". Хотя, как я понял, всё же существуют и рукотворные шаблоны, куда эти кирпичики вставляются в качестве элементов.


[] permanent link

2017/09/15 perl crud

Странно, мне казалось, что я уже исследовал вопрос CRUD в перл, но никакого отчёта не нахожу. Так или иначе, обнаружил у себя установленным вот что:

https://metacpan.org/pod/App::AutoCRUD

Но почему-то не помню, чтобы я его использовал и что-то из этого получилось бы. Позже напишу, что получится.


[] permanent link

2017/08/31 more perl cms

Ещё нечто древнее, но может быть полезно для реализации конкретных фич, которых не хватает современному софту: SSO и подобное.

http://krangcms.com/

http://cms.metadot.com/index.pl?iid=2558

(Update 2020-06-04: сайт Metadot уж не открывается, а вот Krang, судя по скриншотам, в своё время может и мог бы составить конкуренцию Вордпрессу с точки зрения пользователя.)


[] permanent link

2017/08/20 shinycms

Вот такое ещё есть, тоже Каталист, но поскольку уже нашёл себе занятие в виде двух прежде описанных систем, то пока оставлю здесь ссылки:

http://shinycms.org/pages/main/sites https://github.com/denny/ShinyCMS

Тоже всё модное, под докер заточено.


[] permanent link

2017/08/19 pearlbee

Продолжаем разбор подводных камней при установке модных CMS на перл.

PearlBee. Ставить надо версию 1.0, текущая версия с гитхаба представляет собой какой-то недоделанный переходный вариант от мускла к постгресу.

cpanm --installdeps .

Для Authen::Captcha нужен libgd-dev.

Создаём базу:

mysql -u root < db_patches/create_tables.sql

Далее запускаем:

plackup -R lib/ bin/app.pl

Пытаемся зайти в админку (юзер admin, пароль password) по адресу http://localhost:5000/admin (именно так, без слэша: /admin/ не работает! вот как так?) и видим:

Failed to render template: file error — /admin/posts/add.tt: not
found

И так на всех страницах админки. Оказалось, что в новых версиях Dancer не работают следующие конструкции в модулях админки (lib/PearlBee/Admin/*):

   template '/admin/posts/list',

Нужно без начального слэша. Я сначала убрал слэши, но это довольно много автозамены во всех модулях админки. Потом подумал, когда выяснились ещё несовместимости, что лучше ставить старые версии Dancer и других внешних зависимостей, раз уж с этим столько проблем. (На самом деле это конечно не очень правильно и лучше было пропатчить модули, но как мы увидим далее, будут ещё проблемы с DBIC-плагином и его тоже надо будет ставить более ранней версии, которая наверняка зависит от соответственно более ранней версии Dancer.)

Ставим версию 0.11, которая была на момент выпуска релиза PearlBee.

Пока что не ставится. Доставляем модули:

Crypt::URandom
Math::Random::ISAAC::XS
Scope::Upper
URL::Encode::XS
CGI::Deurl::XS
JSON::XS

Ошибка в следующем:

t/charset_server.t ......................... Use of uninitialized value in socket at /home/rp/perl5/perlbrew/perls/perl-5.24.2/lib/site_perl/5.24.2/HTTP/Server/Simple.pm line 705.
socket: Bad file descriptor at /home/rp/.cpanm/work/1503222303.8257/Dancer2-0.11/blib/lib/Dancer2/Core/Runner.pm line 154.
cannot open port: 127.0.0.1:34612 at /home/rp/perl5/perlbrew/perls/perl-5.24.2/lib/site_perl/5.24.2/Test/TCP.pm line 53.

И так далее, как я понимаю, во всех тестах, где надо создавать сокеты.

Сил разбираться с этим нету. Ставим через --force.

Dancer2::Plugin::REST нужно также поставить версии на момент релиза 1.0, иначе Dancer ругается на несоответствие версий.

cpanm --force -v Dancer2::Plugin::REST@0.21

(--force, потому что опять тесты из-за сокета не проходят.)

И удивительное дело! Тут я собирался было писа́ть, что надо ставить старую версию Dancer2::Plugin::DBIC, ибо ранее с последней версией у меня не сохранялись статьи. Однако этого не потребовалось. Всё сохраняется.

Перл v5.24.2 under perlbrew.

Ещё такая особенность, что используются внешние скрипты с ajax.googleapis.com — без них часть функционала админки не работает.

Тестов, кстати, по сути тоже нету.

Возникает вопрос. Как современные программисты пишут и тестят всё это вообще? Про CiderCMS молчу, она не имеет релизов. Но тут? Релиз 1.0 — немногие перл-модули достигают такого. Куча хвалебных публикаций. Всё наимоднейше выглядит, дизайн на JS-фреймворке, Github, MVC: всё моднейшее и современнейшее, что̀ придумано на перл — всё пущено в дело. Аккуратнейший код, всё по правилам Modern Perl — и на̀ тебе, пытаешься ставить и ничего не работает. Это, конечно, вопрос также и к авторам модных фреймворков — они что̀, не в курсе, что их трудами пользуются люди и обратную совместимость нарушать не надо? Или так уже все погрязли в своём гетто что только для себя пишут?

Вот кстати описание работающей системы, которой автор, кажется, доволен: http://perltricks.com/article/69/2014/2/17/Is-PearlBee-Perl-s-next-great-blogging-platform-/

UPD (17.11.2017): Когда попытался ставить не на локалхосте, обнаружилось следующее. Изменения в конфиге не отображаются даже при перезапуске сервера — оказалось, старые настройки сохранялись в сессии!!! Настройки, хранящиеся в базе и меняемые через админку, не сохраняются. Симптомы напоминали прежние неудачи из-за несоответствия версий Dancer2::Plugin::DBIC, но установка старой версии не помогла. Вывод: для продакшена движок не годен. Хотя, понятно, всё это поправимо.


[] permanent link

2017/08/17 cidercms

Так получилось, что мне снова пришлось срочно взяться за поиск подходящей блоггерской CMS на perl.

CiderCMS оказалась на удивление архитектурно вменяемой вещью, вдохновлённой Zope, то есть тем, что я долго мечтал сделать с нуля самостоятельно. Следовательно, удобной скорее для разработчика, чем для конечного пользователя с админскими правами. Странно, что когда всё заработало, я увидел, что всё удивительно знакомо и получается, что я уже ставил её раньше. Но учитывая насколько сложно было разобраться, странно, что я об этом ничего не помню. Да и сохранившихся следов такой установки (инстансов) ни на одном компе не обнаружил.

Мне пришлось установить из репозитория Module::Install. Впоследствии оказалось, что там была версия 1.17 и она годится, а вот 1.18 (текущая в CPAN) уже нет. Кроме того, выяснилось, что нужен модуль Module::Install::Catalyst (в дебиане в пакете libcatalyst-devel-perl — у меня был установлен, но крайне сложно было понять, откуда. В perlbrew -

cpanm -v Catalyst::Devel

Тогда выяснилось, что и Module::Install 1.18 годится. Вообще у Module::Install оказалась такая неприятная черта, что он меняет содержимое каталога и так его и оставляет (добавляет каталог inc). В случае экспериментов с разными версиями модуля/ей создаёт немалую путаницу. Ещё нужна библиотека imlib2 для Image::Imlib2.

Далее, если верить README, достаточно было сказать perl Makefile.PL && make, запустить тестовый сервер прямо оттуда же (script/cidercms_server.pl) и создать инстанс через веб: http://localhost:3000/system/create. Упомянуто, что тесты создают инстанс и заполняют его, поэтому, чтобы сразу посмотреть на всё готовое, я запустил и make test.

Для тестов нужно ещё доставить:

Test::WWW::Mechanize::Catalyst
DBD::Pg (нужна libpq-dev)
Catalyst::Plugin::Authentication
Regexp::Common::Email::Address
Hash::Merge
WWW::Mechanize::TreeBuilder
HTML::TreeBuilder::XPath

Когда тесты не проходили, я обратил внимание на повторяющиеся упоминания DBD::Pg и на то, что создание инстанса по указанному выше урлу выдаёт ошибку подключения к базе. Исследование кода показало, что требуется постгрес, хотя в README об этом не слова.

Постгресу требуется существующая база cidercms и доступ к ней без логина и пароля, т.е. с правами текущего юзера. Кстати, почему-то параметры подключения хардкодно заданы в CiderCMS::Model::DB, а не в каком-либо конфиге. Странный недочёт для столь аккуратно и модульно сделанной системы.

Итак, рутом делаем следующее:

root@acer:~# su — postgres
postgres@acer:~$ createuser rp
postgres@acer:~$ createdb -O rp cidercms

Движок создаёт отдельную схему в базе на каждый инстанс, поэтому таблицы находятся не в схеме public и простое \dt ничего не покажет.

Итак, после установки и настройки постгреса заработал веб-интерфейс и стало проходить больше тестов (но всё равно не все: начиная с какого-то момента тесты падают с ошибкой

could not copy template textfield.zpt

и далее соответственно

unknown type: textfield

).


[] permanent link

2017/01/06 rewrite+userdir

Как известно, mod_rewrite не дружит с mod_userdir. По крайней мере, я о таком где-то слышал. В моём случае это выразилось в том, что внутри userdir (т.е. при запросе к адресу типа http://localhost/~userdir/...) не отрабатывал внутренний редирект на /home/userdir/public_html/... Ошибка выглядела так:

File does not exist: /var/www/home

Исправилось добавлением симлинка /var/www/home -> /home


[] permanent link

2016/11/03 dns

Нынешняя система ДНС чрезвычайно расточительна. Аццкое количество машинного и человеческого времени уходит на разрешение имён (не всегда успешное). Нужны объективные имена хостов, связанные с маршрутизацией. Пока это не так, придётся видимо везде локальные кэширующие НСы ставить, в том числе на телефоны, где постоянное отваливание ДНС и невозможность различить всякие элементарные facebook.com вообще бесит. ДНС гугла не предлагать. Надо глянуть, что̀ умеет всякий dnsmasq, который ныне по умолчанию ставится на многие дистрибутивы и девайсы.


[
] permanent link

2016/10/31 undelete

Вчера сломалась кнопка блокировки экрана на N900, теперь мучаюсь: чтобы заблокировать телефон, нужно не надавить одну удобную кнопку, а сделать 2 более сложных телодвижения. Неудобно настолько, что к телефону почти не прикасаюсь: понял, кстати, что таков может быть способ избавления от телефонной зависимости. Тем не менее, в заметки иногда залезал, хотя 100 лет уже как знаю, что ничего важного в телефоне хранить нельзя и утрачиваю заметки тоже далеко не первый раз. Пытаясь заблокировать экран после добавления мысли в заметку (мысль была о том, что надо автографы давать по-письменному лягушачему, раз уж так их у меня все норовят взять) и нервничая при этом по разным другим поводам, нажал случайно на "Завершить текущую задачу" — заметка при этом с какого-то хера не сохранилась! Мало того, очистилась. (Надо отметить, что заметки вообще оказываются очень уязвимы к таким вещам на всех Нокиях, независимо от ОС.) Расстроенный, пытался утешать себя тем, что ничего ценного в файле не было (потом, после восстановления, оказалось, что это отнюдь не так).

Итак, встал вопрос, как восстановить без вести пропавший файл на телефоне с ОС Maemo. Недолгое изучение интернета показало, что достаточно обойтись grep (GNU) и dd. Рецепт отсюда: http://unix.stackexchange.com/questions/149342/can-overwritten-files-be-recovered.

Вспоминаем, что̀ было в утерянном файле. Помню, что там был стих про Монако.

Nokia-N900:~# /usr/bin/gnu/fgrep -a -b "онако" /dev/mmcblk0p1

Результат выдаёт ряд строк вида

5616632126:<br>в княжестве монако
5632426302:<br>в княжестве монако
5757927742:<br>в княжестве монако
5758976318:<br>в княжестве монако
5759303998:<br>в княжестве монако
5759435070:<br>в княжестве монако
5759566142:<br>в княжестве монако
5762580798:<br>в княжестве монако
5775819070:<br>в княжестве монако

Далее просматриваем наугад отдельные фрагменты:

Nokia-N900:~# dd if=/dev/mmcblk0p1 count=1 skip=$(expr 5616632126 / 512)

Обнаруживаем в некоторых уже более недавние (вчерашние) записи, уточняем по специфическим словам из них:

Nokia-N900:~# /usr/bin/gnu/fgrep -a -b "мастеркит" /dev/mmcblk0p1

И получаем 2 фрагмента (далее происходит "Cannot allocate memory", но спасибо, что хоть эти отыскались), один из которых кажется совсем свежим. Опытным путём подбираем нужное количество блоков и получаем вполне пригодный текст убитого файла.

Nokia-N900:~# dd if=/dev/mmcblk0p1 count=22 skip=$(expr 5973475720 / 512) > /home/user/restored.note.html

Мораль: 1) хватит уже наконец записывать что-либо в телефон; 2) как же прекрасно держать все свои записи в human readable формате; 3) как же прекрасно иметь на телефоне нормальную операционную и файловую системы (последнее хорошо тем, что сохранилась куча версий файла и они не были фрагментированы).

В файле оказалась куча неиспользованных строчек для стихов и ещё много всего.

UPD (Псков, 03.11.2016): ну а вот как обходиться без заметок в телефоне, когда едешь во тьме в автобусе без света, без фонарика (он есть в телефоне, но я забыл про него, да и писа́ть с фонариком неудобно), а мысли так и лезут?


[] permanent link

2016/10/17 simple

В условиях кодинга веб-приложений в путешествии с мобильника Plack оказался малопригоден. Впрочем, цги под классическим веб-сервером (Apache/nginx) тоже, несмотря на доступность их для maemo. (Установка туда plack даже не рассматривается, ибо превзошла бы возможности моего терпения). Решил перейти на запуск цги-приложений под HTTP::Server::Simple, HTTP::Daemon или httpi.

UPD: как раз httpi оказался привередливее всех, а Plack почти что полностью ставится, если вручную доставить некоторые модули. Компилятор не нужен.


[
] permanent link

2016/10/14 offline

Некий (и далеко не единственный, как оказывается) софт для создания оффлайновой копии википедии:

http://wiki.kiwix.org/wiki/Main_Page

И официальные дампы оной:

очень длинная ссылка


[] permanent link

2016/08/22 pl2sql

А вот ещё интересное:

http://search.cpan.org/~tqisjim/NoSQL-PL2SQL-1.21/lib/NoSQL/PL2SQL.pm

Но вот зачем там промежуточный XML?


[] permanent link

2016/08/17 prophet

Случайно нашёл вот такую БД, о которой ничего не известно, но кажется она почти мне подходит:

http://search.cpan.org/~ioanr/Prophet-0.751/

Смущает только, что оно для small и medium баз.

И там же, оказывается, используется подходящий мне шаблонизатор:

http://search.cpan.org/~alexmv/Template-Declare-0.47/


[] permanent link

2016/08/12 dezi

http://dezi.org/ — поисковик на Перл, форк Swish, что уже хорошо. При этом сайт на вордпрессе. Пока не пробовал, боюсь разочароваться. Не люблю это всё бесчисленные апачины отпрыски (там Apache Lucy используется), но если это будет работать, то почему бы не начать уже сейчас.


[] permanent link

2016/04/28 perl dom

"I'm not a fan of template languages, preferring DOM manipulation."

http://blogs.perl.org/users/toby_inkster/2012/10/in-a-simple-mojoliciousdbi-example.html

Там же ссылка на CR(UD) для Mojolicious в несколько строчек:

http://blogs.perl.org/users/joel_berger/2012/10/a-simple-mojoliciousdbi-example.html


[] permanent link

2016/04/02

Глокая куздра как критерий русскости

Уже много лет я думаю о создании нормального поисковика для посрамления корпоративного поделия Гугла.

Однажды я даже пытался было взяться за одну из подзадач этого дела — распознавание языка и анализ морфологии. И оказалось, что практически все существующие морфологические анализаторы работают со словарями — конечными наборами данных. Практически все определители языка используют всё те же словари, N-граммы (которые также получены из словарей или из текстов) и/или рассчитаны на обучение — то есть не работают «из коробки», и успех их зависит от качества исходных словарей или текстов и старательности обучающего.

При таком подходе создание морфологических анализаторов для малых языков (либо мало представленных в электронном виде) упирается в непосильную задачу составления словарей или поиска приемлемых текстов (которые, в свою очередь, в интернете найти не так-то просто из-за отсутствия способа опознать данный язык).

И при этом словарный подход вообще не кажется мне удачным. Ибо человек вполне способен определить язык текста, не зная ничего ни о каких словарях.

В советское время была выпущена книжка «Определитель языков мира по письменности», а в «Химии и жизни» была статья «Как узнать незнакомый язык». Книжку я лишь скачал и ещё не читал, но статья на неё ссылается. Статьёй же я всё детство зачитывался. Описанный там способ мне всегда казался само собой разумеющимся. Точно так же обычно построены определители животных или растений: ищется в тексте некий признак (буква, буквосочетание, служебное слово), в зависимости от результата ищется следующее, пока не пройдём всю череду признаков, уникально идентифицирующих язык.

Исходить нужно из того, что словарный подход вообще не работает в некоторых случаях. Например, знаменитую фразу «Глокая куздра штеко будланула бокра и курдячит бокрёнка» наше сознание легко идентифицирует как русскую, хотя слов таких в словарях нет (кроме «и»), мало того, даже отдельные вырванные из неё подфразы типа «штеко будланула» или «куздра курдячит» вполне могут быть опознаны как русские или по крайней мере (восточно-)славянские.

Таким образом, задача определения языка выполняется, если фраза про глокую куздру (или даже её фрагменты) может быть распознана как русская без помощи каких-либо словарей, без какого-либо обучения (конкретному языку) и без предопределённых списков N-грамм (хотя в процессе анализа некие внутренние списки и могут создаваться). Морфологические (и синтаксические) анализаторы должны обрабатывать эту фразу как любую другую на русском языке.

UPD: Уже закончив эту заметку, я обнаружил и стал читать книжку венгерской переводчицы Като Ломб «Как я изучаю языки», где она рассказывает, как самостоятельно «расшифровывает» язык, в том числе склонение и спряжение. Естественно, такая расшифровка возможна лишь при некотором знании других языков, родственных или типологически близких расшифровываемому. Однако это всё равно позволяет ограничить набор требуемых исходных данных. Вот несколько цитат из книги, иллюстрирующих метод:

Первой книгой для учебного чтения был один из романов Голсуорси. Через неделю я стала догадываться, о чем там идет речь, через месяц я понимала; а через два месяца уже наслаждалась текстом.

А однажды на рассвете, в конце декабря, я приступила к самостоятельной расшифровке первого китайского предложения. Было уже совсем поздно, когда я добилась результата.

Я без промедления купила роман Ивана Ольбрахта «Анна-пролетарка» и, пользуясь своим уже привычным способом, распутала по тексту загадку склонений и спряжений.

Прочтя книгу, я проверила себя по хорошему учебнику Рудольфа Кирая, верно ли я вывела из текста основные грамматические правила.


[] permanent link

2016/03/04 template pod

Сегодня, моясь в ванной, подумал, что можно было бы в качестве шаблонизатора на все случаи жизни использовать POD. Потом понял, что таким образом можно и включать куски кода в шаблоны — файл шаблона будет обычным перл-скриптом с чередованием кода и pod. На выходе получаем HTML.

Идея настолько проста, что я подумал, что Template::POD, конечно же, уже существует. Принялся его искать -- но нет! вроде как нету такого. Нашёл только вот это: http://search.cpan.org/dist/WriteAt/ — для pod6. И его же: http://search.cpan.org/~zag/WebDAO-2.25/. Там автор, как я понял, вообще отказывается от вывода в HTML в пользу JSON/XML, что мне вовсе не требуется, я собирался просто генерить вывод чем-то вроде pod2html.


[] permanent link