суббота, 21 сентября 2019 г.

Пингвин-фотолюбитель: 6. Darktable — (не очень) быстрый старт

Со времени моего прошлого поста про Darktable прошло, страшно подумать, три с лишним года. За это время и инструмент вырос (версия 2.6.2 сейчас у меня вместо 2.0.4), и я научился им лучше пользоваться.

Кстати, за это время вышла официальная сборка Darktable под Windows. Если кому не хочется пиратить Lightroom, а с винды не слезается — пользуйтесь. Правда, про стабильность/надежность ничего не знаю.

А еще я недавно с удивлением и радостью обнаружил в сети неплохой перевод «Руководства пользователя Darktable». Там по версии 2.4, но от 2.6 оно мало отличается, к тому же всегда в спорных моментах можно обратиться к актуальному англоязычному мануалу. Перевод же от всей души рекомендую в качестве обзора возможностей (и особенностей) программы. В дальнейшем я буду ссылаться на обе версии документации в виде «Термин[ru/en]».

Итак. Настоящим постом я хочу рассказать, какие я использую настройки для уменьшения телодвижений в процессе обработки фотографий, и какие же движения никто не отменял. Сразу скажу, что это а) мой личный опыт, б) только базовая обработка. Повторять страницы мануала нет никакого желания, а если говорить об осмысленном применении всех возможностей, то и компетентности.

среда, 17 июля 2019 г.

Поиздевался над железками

У меня было два HDD, два SSD, два внешних USB-диска (HDD) и сколько-то SD-карт. Не то, чтобы все это было нужно протестировать, но раз начал коллекционировать цифры MB/s, нужно идти в этом своем увлечении до конца. Единственное, что меня беспокоило — это флэшка-брелок. В мире нет ничего более бессмысленного и редко используемого, чем флэшка-брелок.

В общем, руководствуясь скорее бессонницей, чем необходимостью, замерил скорости чтения/записи для нескольких девайсов, которые оказались под рукой (ну и тех, что и так в корпусе компьютера). В первую очередь меня интересовали скорости имеющихся SD-карт, а также влияние на эти скорости USB-хаба и кард-ридера (у меня их два разных).

Способ тестирования

Замеры делались следующими командами (первая для записи, вторая для чтения):

# dd if=〈файл на tmpfs〉 of=〈файл на целевом устройстве〉 bs=1M count=1K oflag=sync
# sync; echo 3 > /proc/sys/vm/drop_caches ; dd of=〈файл на tmpfs〉 if=〈файл на целевом устройстве〉 bs=1M count=1K oflag=sync

Сам этот гигабайтный файл предварительно был сгенерирован из /dev/urandom посредством все того же dd. Непосредственно брать из /dev/urandom теоретически было бы лучше, но увы, он оказался медленнее, чем SSD. Использовать /dev/zero и /dev/null я не стал во избежание каких-нибудь оптимизаций со стороны системы.

Указанные команды выполнялись по несколько раз для каждого устройства, пока не начинали давать более-менее стабильный результат (стабильность определялась на глаз), после чего последние пять таких стабильных результатов усреднялись и округлялись до целых мегабайт. О некоторых интересных нестабильностях я напишу ниже. Отмечу, что в результатах десятичные, а не двоичные мегабайты, т.е. 1 MB = 1 000 000 B, впрочем, в стандартах и характеристиках от производителя обычно указываются они же.

Disclaimer: описанное в этом посте не является корректным тестированием и сравнением чего бы то ни было — очень многое делалось на глаз, а тестируемые девайсы находились в совершенно разных стадиях износа и заполненности. Да и нагрузка 1GiB кусками по 1MiB не соответствует ни реальным кейсам, ни любимым тестам производителей и обзорщиков. Зато удобна. В общем, автор в курсе, автор не претендуэ. Автора интересовало исследование скопившихся у него девайсов в текущем состоянии, способом, худо-бедно соответствующим текущим задачам (не всем).

tl;dr: в целом, результаты соответствуют ожиданиям, а китайские бренды (ORICO и noname) проявили себя вполне неплохо.

понедельник, 4 марта 2019 г.

Всё для людей!

Ковыряюсь тут с PostgreSQL и вот какую замечательную штуку обнаружил...

Собственно, про существование «updatable views» я знал, и давно. Но пока не доводилось использовать. И я думал, что для того, чтобы они заработали, нужно прописывать правила для всех действий. Однако нет — простые представления делаются изменяемыми автоматически, т.е. пишем, например:

... и всё, этого достаточно — можно обращаться к представлению something так же, как к таблице — вставлять, изменять, удалять по id.

Отдельно хочу обратить внимание на индекс с выражением where — он контролирует уникальность поля, но на записи с пометкой удаления этот контроль не распространяется, т.е. для того, кто работает с представлением, их как бы нет, без скрытых эффектов. И да, если мы попробуем запросить данные из something с сортировкой по name, при достаточно большом количестве записей этот индекс будет задействован, проверено.

Для полного счастья остаётся один штришок — таки переопределить одно правило:

Теперь удаление через представление будет лишь ставить пометку удаления в реальных данных.

Что это нам даёт? Например то, что мы можем дать «обычному» пользователю БД (скажем, тому, под которым ходит веб-приложение, находящееся в страшном и опасном диком интернете) права на представление и не дать непосредственно на таблицу, таким образом слегка себя обезопасив от некоторых непоправимых действий. Особенно, если это не просто приложение, а открытое API. А админка пусть ходит под более уполномоченным пользователем.

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

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