shoorick: (Default)
Понадобилось вчера распечатать большую картинку (схему БД из Drupal 7). Размер картинки — более 2K×2K, на листе формата A4 смотрится совершенно нечитаемо.

Что делать? Разбивать на кусочки. Вариант простой и тупой (но неправильный) — использовать Inkscape: открыть картинку, увеличить, поместить её на лист нужного размера, ( двигать и печатать ) × n.

Погуглив, нашёл другой метод: использовать команду poster. Попробовал — работает. Увеличить исходную картинку (Encapsulated PostScript формата A4) и разрезать на кусочки того же размера можно, например, так:
poster -v -pA2 drupal7_model_0.eps > many-pages.ps
Правда, результат вышел даже крупнее, чем A2 — картинка растянулась на 6 листов A4 (судя по мануалу, это не баг — это фича), но в моём случае это не страшно.

Получившийся многостраничный PostScript-файл можно спокойно печатать и потом склеивать листы.

Драйверы некоторых принтеров умеют делать то же самое без всякой командной строки (я такое как-то видел), но в моём случае я такой возможности не нашёл.
shoorick: (Default)
Обнаружил у Анатолия Шарифулина в твитере ссылочку на очередной метод построения картинок без помощи графического редактора: ditaa — программа, которая чертит диаграммы, принимая в качестве исходного текста обычный текстовой файл, где нужные фигуры обозначены нарисованы символами <:*|+->. Я попробовал — получается. Например, из файла, описывающего некую структуру базы данных
              /---------------------------\
+---------+   : +----------+    +-------+ |
| pages   |   | | user     |    | group | |
+---------+   | +----------+    +-------+ |
| id      | +-->* id       | +->* id    | |
| owner   *-+ | | group    *-+  | name  | |
| title   |   | | login    |    | descr | |
| content |   | | password |    +-------+ |
+---------+   | +----------+              |
              \---------------------------/

получается картинка:

Результат работы ditaa

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

Re: Ой

Dec. 7th, 2009 09:52 pm
shoorick: (Default)
Поглядев на терзание сервера баз данных нашей поделкой, решил попробовать другой метод: DBIx::Class, вроде бы, позволяет выполнять произвольный SQL-запрос. Запрос-то я написал и протестировал, да вот подсунуть его каталисту пока не получается...

Пойду-ка домой, ужинать и читать мануалы.

Ой

Dec. 7th, 2009 05:45 pm
shoorick: (Default)
Прочитал про отладку в DBIx::Class, включил вывод запросов в лог — ужасаюсь: на отображение одной странички ушло 140 (сто сорок!) запросов (среди них — немало повторяющихся). Даже если СУБД и выдаёт результаты из кэша — это всё равно слишком много. Я, конечно, понимаю, что использование ORM может подразумевать некоторое увеличение использования машинных ресурсов в обмен на экономию времени программиста. Но не до такой же степени!
shoorick: (Default)
Задавшись целью отслеживать в траке (trac) свежие тикеты (таймлайн для этого не совсем удобен, ибо содержит массу других событий и фиксирует только появление/закрытие/повторное открытие) и комментарии к ним, нашёл механизм: через отчёты.

Сделал три отчёта )

Получил искомое. Доволен.

shoorick: (Default)
Разгребал старые тикеты от разрабатываемого на Catalyst + DBIx::Class проекта, наткнулся на один из: в БД не вставляются файлы, размером больше, чем @@max_allowed_packet (а, наверное, и ещё меньше; в моём случае максимальный размер — около мегабайта), а @@max_allowed_packet на ходу меняться не хочет. Гуглил методы обхода или, например, готовые решения вставки по кускам (ибо самому писать слегка лениво) — в итоге напоролся на DBIx::Class::InflateColumn::File: хранение файлов в файловой системе с доступом к ним через DBIx::Class. Удивительно...
shoorick: (Default)
Жила-была таблица teacher_subject_stgroup и мозолила глаза длиной своего имени и вечным выпиранием его из красивой картинки со структурой базы данных. Но из соседних таблиц можно было запросто обратиться к ней, сказав, например,
$c->stash->{'teacher_subjects'} = $stgroup->teacher_subject_stgroups;
Однако, надоело — переименовал таблицу в tss. Несколько дней потом безуспешно пытался выполнить $stgroup->tsss. И лишь сегодня обнаружил, что надо было искать не tsss, а tsses. Потому что множественное число, а не просто $word . 's'. Lingua::EN::Inflect::Number, однако...
shoorick: (Default)
Может ли планарность графа структуры базы данных быть критерием её оптимальности?
shoorick: (Default)
Задача: вручную изменить значение какого-либо поля в форме после обработки её методом result, но до вставки результата методом populate_from_widget. Решается при помощи HTML::Widget::Result::add_valid:
sub create_do : Local {
    # SKIPPED
    # Validate the form parameters
    my $result = $w->process($c->req);

    # Were their validation errors?
    if ($result->has_errors) {
        # SKIPPED
    }
    else    {
        # SKIPPED
        # Меняем значение поля password
        $result->add_valid('password', Digest::SHA1::sha1_hex($password));
        # SKIPPED
        my $user = $c->model('Dbase::User')->new()->populate_from_widget($result);
        # SKIPPED
    } # else без ошибок
    # SKIPPED
} # sub create_do
shoorick: (Default)
Пытаюсь понять, как работает many_to_many в DBIx::Class — ни хрена не понятно :-(
Плюс к тому мануалы написаны по-дурацки: вместо того, чтобы подробно описать параметры используемых функций, автор ограничился парой примеров. За что и поимел — вынужден отвечать юзерам, что всё устроено не так, как они понимают.
shoorick: (Default)
Ковыряться в тонне однотипных исходников, пытаясь в редакторе найти нужный кусок и заменить на что-то новое — не наш метод. Наш метод:
sed -e "s/Page/Teacher/g" -e "s/page/teacher/g" -e "s/Subject/Dept/g" -e "s/subject/dept/g" PageSubject.pm > TeacherDept.pm
Хотя подозреваю, что и это — не самый оптимальный из возможных путей.

upd:Таки да, есть ещё более весёлый метод: запустить helper, который сразу генерит всю толпу модулей. Например, так:
script/app_create.pl model Dbase DBIC::Schema Dbase create=static dbi:mysql:БД[:хост] логин пароль
shoorick: (Default)
Наступил на чужие грабли. Нагуглил причину:
"Can't locate object method "compose_namespace" via package "Db"
Don't call your database class 'Db'.
DB is the namespace reserved for the perl debugger.
Пофиксил. Теперь не ругается. Осталось заставить работать...
shoorick: (Default)
А ещё оно умеет плейсхолдеры с автоматическим квотингом:
#!/usr/bin/perl -w
use strict;

use DBI;
# skipped
my $hashref = $dbh->selectrow_hashref(q{SELECT * FROM fruit WHERE `name`=?}, undef, q{john's pear});
Даже с MySQL/3.23 такой фокус проходит...
shoorick: (Default)
Читай man, читай man, читай man... Ну и perldoc. И снова: читай man, читай man...
Глянув поутру в perldoc DBI, очередной раз понял, что делаю всё неправильно: пользуюсь самописным лисапедом (причём, давно пользуюсь: отдельные его методы существуют уже лет семь), выполняющим $dbh->prepare(), $dbh->execute(), а затем, если $sth->rows позволит, в цикле выбирающем строки при помощи $sth->fetchrow_hashref. В то время как ракеты бороздят существуют $dbh->selectall_hashref, $dbh->selectcol_arrayref и $dbh->selectrow_hashref.
Поздравляю тебя, Шарик Shoorick — ты балбес!

Profile

shoorick: (Default)
shoorick

December 2016

S M T W T F S
    1 23
45678910
11121314151617
18 19 2021222324
25262728293031

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 7th, 2025 06:59 pm
Powered by Dreamwidth Studios