Пробую вышедший недавно четвёртый pgAdmin — а это (внезапно!) веб-приложение, как сейчас модно. Ладно хоть, не тащит за собой ни хром, ни мозиллу, а запускается в новой вкладке существующего браузера. Написано на питоне, весит 22 МБ, из коих половина — картинки, клиентские скрипты, шрифты да переводы.
Из перлового веб-фреймворка Mojolicious начиная с вышедшей ровно четыре месяца назад версии 8.0 убрана команда test
Теперь вместо этой команды надо использовать prove.
ICQ (точнее, Mail.ru Group), похоже, хочет заставить пользователей переползти на использование нового клиента. Мне кажется, эффект будет обратным — народ разбежится.
Вот я, например, не собираюсь ни с отдельным клиентом возиться (мне универсального Пиджина хватает), ни держать аську в браузере — и без неё десятки вкладок иногда открыты. Так что если с нового года моя ромашка покраснеет — значит, пишите письма. Почта куда надёжнее аськи.
ImageMagick позволяет собирать многостраничный PDF-файл из нескольких растровых картинок, но не всегда — на некоторых компьютерах выдаёт ошибку
convert: not authorized `result.pdf' @ error/constitute.c/WriteImage/1028.
Причина — в том, что в конкретном экземпляре может быть запрещено создавать PDF, но есть рецепт, как это исправить: в файле /etc/ImageMagick-6/policy.xml надо включить нужное разрешение — строку
<policy domain="coder" rights="none" pattern="PDF" />надо заменить на
<policy domain="coder" rights="read|write" pattern="PDF" />После этого PDF-файл будет нормально создаваться.
Теперь осталось понять, почему же готовый файл вдвое тяжелее суммы исходных. Добавление в команду преобразования параметров -dither none -colors 2 на размер готового файла практически не влияет.
Перловый микрофреймворк Mojolicious::Lite умеет сам выдавать существующие файлы, но при этом не все из них получают верный тип содержимого Content-type: некоторые файлы прикидываются обычными текстовыми (text/plain), другие же вообще не имеют никакого типа — браузер такие файлы может воспринимать как угодно. В состав фреймворка входит модуль Mojolicious::Types, в котором определены MIME-типы для наиболее популярных (most common) расширений файлов:
appcache -> text/cache-manifest atom -> application/atom+xml bin -> application/octet-stream css -> text/css gif -> image/gif gz -> application/x-gzip htm -> text/html html -> text/html;charset=UTF-8 ico -> image/x-icon jpeg -> image/jpeg jpg -> image/jpeg js -> application/javascript json -> application/json;charset=UTF-8 mp3 -> audio/mpeg mp4 -> video/mp4 ogg -> audio/ogg ogv -> video/ogg pdf -> application/pdf png -> image/png rss -> application/rss+xml svg -> image/svg+xml txt -> text/plain;charset=UTF-8 webm -> video/webm woff -> font/woff woff2 -> font/woff2 xml -> application/xml,text/xml zip -> application/zip
странно, но среди них нет ни одного, относящегося к офисным пакетам. На сайте Microsoft | Developer можно найти список типов — Office 2007 File Format MIME Types for HTTP Content Streaming. Чтобы не задумываться, какие же из этих типов брать, можно сохранить все — если есть какой-нибудь конфигурационный файл, он вполне подойдёт для хранения такого списка. В моём случае конфигурационные файлы обычно в формате YAML — это удобно.
---
# ... ещё какие-нибудь параметры
# MS Office types
types:
rtf: application/rtf
doc: application/msword
dot: application/msword
docx: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Где-нибудь перед запуском приложения надо добавить типы (допустим, конфигурация приложения доступна через $config)
while ( my ( $ext, $type ) = each %{ $config->{'types'} } ) {
app->types->type($ext => $type);
}
Правда, при выдаче файла тип его содержимого придётся всё-таки указать явно, иначе Mojolicious вернёт тип только для знакомых файлов, а для офисных будет undef
my $type = $self->app->types->mapping->{$ext}->[0];
if (my $asset = $self->app->static->file("/$path/$id.$ext")) {
$self->res->headers->content_type($type);
return $self->reply->asset($asset);
}
else {
return $self->reply->not_found;
}
Теперь и офисные файлы возвращаются нормально.
Линуксовая команда sort (во всяком случае, в Ubuntu 16.04 LTS) почему-то сразу сортирует без учёта регистра, хотя такое поведение должно включаться специальным ключом -f либо --ignore-case. Ключа --no-ignore-case для выключения такого поведения нет. Выход — сортировать перловым однострочником
perl -0777 -ne 'print join "\n", sort split "\n"'
В состав перлового микрофреймворка Mojolicious::Lite входит класс Mojo::Log, который не просто пишет сообщения в лог, а ещё и учитывает важность сообщений — в отладочном режиме пишет много, а боевом — мало. Обнаружилось, что сообщения об ошибках имеют тот же класс debug, что и остальные сообщения
[Tue Nov 13 12:25:51 2018] [debug] Format html [Tue Nov 13 12:25:51 2018] [debug] 200 OK (0.076118s, 13.137/s) [Tue Nov 13 12:25:53 2018] [debug] GET "/some/url" [Tue Nov 13 12:25:53 2018] [debug] Template "not_found.development.html.ep" not found [Tue Nov 13 12:25:53 2018] [debug] Rendering template "not_found.html.ep" [Tue Nov 13 12:25:53 2018] [debug] Rendering template "layouts/error.html.ep" [Tue Nov 13 12:25:53 2018] [debug] Rendering cached template "layouts/admin.html.ep" [Tue Nov 13 12:25:53 2018] [debug] Rendering cached template "search_form_navbar.html.ep" [Tue Nov 13 12:25:53 2018] [debug] Format html [Tue Nov 13 12:25:53 2018] [debug] 404 Not Found (0.004841s, 206.569/s)
из-за чего при запуске в продакшне под реальной нагрузкой в лог не попадает почти ничего — например, там нет сообщения об ошибках 404 Not Found.
Возможно, где-нибудь во внутренностях Mojo можно исправить такую ситуацию, но мы пойдём другим путём — применим хук after_dispatch:
hook after_dispatch => sub {
my $self = shift;
my $req = $self->req;
my $res = $self->res;
if ( $res->code >= 400 ) {
$self->app->log->error(join ' ',
'"' . $req->method . ' ' . $req->url . '"',
$res->code,
$req->headers->referrer || '-',
'"' . $req->headers->user_agent . '"',
);
}
};
Результат — в логе появились сообщения об ошибках:
Sending children hup signal [Tue Nov 13 12:30:46 2018] [error] "GET /none" 404 - "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36" [Tue Nov 13 12:44:50 2018] [error] "GET /SW/Rplayer.html" 404 - "Mozilla/5.0 (compatible; Linux x86_64; Mail.RU_Bot/2.0; +http://go.mail.ru/help/robots)"
Документация по языку Perl и его модулям теперь доступна и на perldoc.pl, только оно без прокси не работает, ибо заблокировано роскомпозором. Точнее, заблокирован IP-адрес (IPv4, конечно), на котором сидит этот сайт. И lilypond.org без прокси не откроется, и toggl.com, и oEmbed.com…
Попробовал решить одну из рабочих задач, применив нелюбимый язык PHP в комплекте с современными инструментами — получилось близко к тому, что делал сравнительно недавно на перле, с некоторыми отличиями:
Практика показала, что разобраться с подобным комбайном можно достаточно быстро. Код при этом получается чуть более многословным, чем в Mojo, но всё равно компактным и понятным.
Мы стали более лучше одеваться^W^W^W правильнее склонять имена с фамилиями. Вчера вышла свежая версия предназначенного для этого перлового модуля Lingua::RU::Inflect (он же есть и на гитхабе — чуть свеже́е, чем на CPAN).
На днях по рабочей необходимости сгенерировал родительный падеж более, чем на четырёх тысячах реальных имён — почти один процент из них оказался с ошибками — пришлось исправить модуль, за который я четыре года не брался.
Итак, в новой версии:
В итоге количество ошибок на тестовом наборе данных сократилось в 2–3 раза, до одной ошибки на 200–300 человек — есть неочевидные случаи, потому и оценка приблизительна. Двойные имена и фамилии пока слоняются неправильно — исправлю как-нибудь потом.