November 22nd, 2016

404

Разбираясь с формами

В настоящий момент, кроме общего "не точно рисую" (скилл "точно рисовать" не имеет верхней границы и должен совершенствоваться всё время), главной проблемой я ощущаю неспособность передавать форму через тон. Линейный рисунок ограничен в передаче сложных объектов, потому что многие объекты имеют мягкие формы, в которых невозможно показать "границу между планами" (попробуйте разобрать по планам куриное яйцо). При этом вполне возможно убедительно нарисовать его всего лишь срисовывая пятнышки, что работает только если эти пятнышки self-explained. Чем сложнее объект, тем больше там есть пятнышек, которые нужно "дорабатывать", показывая их реальную форму (пример: впадинка, освещённая спотлайтом - надо и впадинку показать, и спотлайт, а если пятнышки перерисовывать, будет чушь).

Ярче всего это заметно на складках, которые я чаще всего не могу нарисовать, а если что-то "вроде бы круто" и получается, то по ошибке и совсем не так, как оно IRL.

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

Пока что простейшие формы (пока сканил - обнаружил, что линейный рисунок "так себе", потому что перспектива местами сильно плывёт - халтура, да).
Collapse )
Следующее упражнение будет сложнее - два сглаженных угла. Потом, видимо, два разных сглаженных угла, с разным радиусом изгиба. Потом два одинаковых угла, но с разной степенью сглаженности.

(заметка для себя: не рисовать на офисной бумаге даже для "упражнений". Она отвратительна).
404

latency versus thoughtput

Практически идеальная иллюстрация:

#1
fio --name `hostname` --blocksize=4k --ioengine=libaio --iodepth=1 --direct=1 --buffered=0 --rw=randwrite --filename=/mnt/bench --fsync 1

#2
fio --name `hostname` --blocksize=4k --ioengine=libaio --iodepth=1 --direct=1 --buffered=0 --rw=randwrite --filename=/mnt/bench

Первое: 395 iops, max_latency = 3500us, 99.9% < 109 us

Второе: 20530 iops, max_latency = 1137.2Kus (==1.1s), 99.9% < 70 us

Я не считаю такое поведение нормальным (явно кривая SSD), но всё-таки показательно. 400 IOPS'ов, зато настоящих. 20к IOPSов, зато best efforts, которые не всегда best.
404

devops сверху и девопс снизу

Главная страшная вещь в devops'е - совершенно необъятный фронт компетенции. В любой момент может оказаться, что (очередной следующий пакет) использует что-то невообразимо сложное, о чём раньше ни сном ни духом. То есть нужно собрать маленькую библиотечку на питоне, но её авторы делали её в контексте своего видения мира и она должна собираться как часть сборки mono-приложения. Или с участием nmp. Или cargo. Или ещё чего-то такого. Что, может быть, даже не является best practice и возникло от того, что кому-то было лениво посмотреть как это делать правильно и он сделал "как смог".

Так что открывая очередной setup.py на 329 строк (привет, imageio), всегда надо быть готовым к самому странному методу сборки какой только можно придумать. Или к необходимости выяснять "как оно устроено и что делает" (например, товарищи могут решить, что их make не устраивает и заюзать ninja - привет, ещё один мануал).

Так что получается, что это devops снизу - когда сталкиваешься с незнакомыми приложениями, экосистемами, и, может быть, даже системами дистрибьюции кода (а тут мы динамически подтягиваем с помощью bzr скрипт, который нам соберёт питоновую библиотеку из xml/xlst, генерируемых перловым враппером над mono'шным скриптом сборки 300 мегабайтного монста, у которого список зависимостей на 4 листа).

А бывает devops сверху - это когда ты знаешь все используемые компоненты и приёмы и читаешь его, как обычный программист читает код на code review.

Вот devops сверху - это приятно и весело. А вот devops снизу - это ад и погибель.