🔑 Мастер ключей

Схематичное изображение ключа с круглой головкой, внутри которой изображён символ серпа и молота.
Ключ №1 СССР, от входной двери в Мавзолей

Это Главный ключ страны, мы называем его «Ключ № 1 СССР». Он от входной двери в Мавзолей.

Согласитесь, что мне было бы очень трудно объяснить следователям КГБ, зачем и с какой целью я срисовал этот ключ в масштабе 1:1, если бы меня поймали за этим занятием.

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

Цитата из книги «Байки старого телемастера» Геннадия Гендина. Очень и очень рекомендую книгу, совершенно роскошная, читается на одном дыхании. Будет интересна буквально всем своими уникальными деталями советского быта — по роду работы автор был вхож в дома многих советских деятелей и даже в Кремль. Ключ, которые вы видите выше, он срисовал именно там.

6 комментариев

👁 Глаз следящий

Скриншот интерфейса терминала iTerm2 на macOS с открытыми вкладками пользователя evgeny.stepanischev и видимыми элементами меню и док-панели.
Глаз, следящий за мышью в консоли

Обновилась до версии 2.9 моя любимая программа-терминал iTerm2. Изучая новые возможности, обнаружил нечто неожиданное — теперь в консоль можно выводить обычные графические изображения.

Протокол довольно простой:

ESC ] 1337 ; File = [необязательные параметры] : изображение в формате base64 ^G

Решил немного с ним побаловаться, результат на скриншоте — небольшая программа на «баше» — глаз, который следит за указателем мыши.

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

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

Для запуска требуется iTerm2 2.9 и выше и Imagemagick.

4 комментария

💰 Шалаш на острове сокровищ—2

Результат выезда (64.26КиБ)
Ранние «советы» и монета ГДР

Сегодня постарались целенаправленно поискать монеты по домам. Жилой дом не порадовал буквально ничем, а вот бывший сельский магазинчик принёс 51 монету, правда по большей части — поздние «советы», их я даже фотографировать не стал.

Сверху на фотографии 1 пфенниг ГДР 1977 года, далее по номиналам: 3 копейки 1930 и 53 годов, 5 копеек 1928, 31 (2 штуки), 46, 54 и 55 годов, 10 копеек 1939 года, 15 копеек 1952, 53 и 55 годов, 20 копеек 1948, 54 (2 штуки) и 1957 годов.

Самая старая монета за сегодняший выезд — 5 копеек 1928 года.

7 комментариев

🌀 Мельница в селе Симетбаш

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

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

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

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

Фото выше делал на просунутый в окно фотоаппарат. Это действительно оказалась мельница, с электрическим приводом. Причём действующая до сих пор — к ней подведено электричество.

Гугление ничего не дало, поэтому решил написать в блоге — вдруг кто опознает постройку и расскажет её историю.

Оставить комментарий

💰 Чистка монет: «никель», ранние «советы»

Почищенные ранние советы (41.99КиБ)
Почищенный «никель» — 20, 15 и 10 копеек ранних «советов»

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

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

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

Учитывая их первоначальное состояние, результат великолепный.

7 комментариев

🏠 Кирпичи из дома Микляева (Михляева)

Сегодня повторно побывал в Доме Микляева, там вовсю идёт реставрация, за которой очень интересно наблюдать. В частности, к кирпичам «МЧ» добавились другие, с более интересными клеймами.

Крупный план красной кирпичной стены с надписью «МН» на переднем кирпиче, выполненной углублением в глине.
Клеймо Марии Челышевой, многократно попадается во внешней стене дома

Клеймо Марии Челышевой, владелицы кирпичного сарая при деревне Малые Клыки в конце 19 века мне попадалось на левом углу дома, в этот раз я разглядел его и справа. Этих кирпичей вообще там много, видимо дом неоднократно ремонтировался.

Старый кирпич с оттиском «КАМЕННЫЙ ЗАВОД» на фоне других кирпичей.
Клеймо Нижегородского Завода Огнеупорных Изделий

А это уже кое-что новенькое, едва удалось рассмотреть буквы. Это клеймо Нижегородского Завода Огнеупорных Изделий. На что указывает литера «А» посередине мне неизвестно. То ли на фамилию владельца, то ли на местность.

Обломок красного кирпича с оттиском клейма «А. А. Аустинъ» и изображением двуглавого орла, лежащий на светлой стене.
Клеймо завода Ивана Афанасьевича Костина

Другой новичок носит клеймо завода, принадлежавшего крестьянину Ивану Афанасьевичу Костину. В 1862 году он основал гончарный, изразцовый и кирпичный заводы в Нижнем Новгороде. Впоследствии был основан «Торговый Дом И.А.Костин с племянниками», кирпичи с клеймами которого попадаются в интернете.

3 комментария

💰 Шалаш на острове сокровищ—3

Третий выезд в дома (45.30КиБ)
Добыча последних выездов: две царских, пять советских

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

Мы, естественно, полы не вскрываем, а просто ищем дома, где время или предприимчивые соседи постарались до нас. В этот раз добыча очень разнообразная.

Сверху и снизу — медные цепочки, скорее всего два обрывка одной более длинной.

В первом ряду — пять копеек 1911 года, 10 копеек 1914 (моё первое монетное серебро!), крышка от небольшого графинчика, свинцовая пломба (думаю, советских времён, на одной стороне «Т», на другой — что-то вроде ноты), две армейские дутые пуговицы со звездой.

Во втором ряду — ранние советы (поздние фотографировать не стал). Это одна копейка 1935 года, и две копейки 1945, 1946, 1949 и 1956 годов.

Некоторые монеты пришлось серьёзно почистить. Проще всего было с серебряной — опустил несколько раз в специализированное средство «Аладдин» и монета чистая, а когда я её подбирал, она была такой тёмной, что я перепутал её с советской.

«Советы» я сначала сварил в соде, чтобы убрать зелёные наросты (наверное это медный купорос), потом положил в уксус, чтобы уменьшить красноту после соды и в конце почистил «Асидолом-М» (специальное средство для чистки металов), что почти убило жёлтый окрас. После этого монеты на годик кладут на окно, под солнце, чтобы вернуть цвет.

23 комментария

🐘 «Рекурсивные» запросы в PostgreSQL

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

Если вы знаете рецепт лучше, поделитесь, пожалуйста.

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

Есть такой и для «рекурсивных» запросов. Нередко «рекурсивный» запрос приходится строить, выбирая не из таблицы, а из подзапроса. Наш билдер был устроен таким образом, что подобный запрос он строил по следующему образцу:

WITH RECURSIVE prior AS (
    WITH virtual AS (
        -- тут у нас подзапрос
    )
    SELECT … FROM virtual WHERE …некий критерий…
    UNION ALL
    SELECT … FROM virtual INNER JOIN prior …критерий соединения…
)
SELECT … FROM prior…

Ну вот что-то такое. Оказалось, конструкция WITH является барьером для постгреского оптимизатора — он не может заглянуть за него и планы строит отдельно — для запроса внутри WITH и того, что снаружи. Разумеет это дико неэффективно. Например, если внутри соединение со слабыми ограничениями (сильные наложатся снаружи — в «рекурсивном» запросе), то внутренний запрос может выбрать гигантское количество данных, что у нас и происходило в нескольких местах.

Эффективнее оказалось убрать внутренний WITH и повторить запрос дважды — в выборе первой строки и внутреннем соединении. Но беда в том, что билдер так сделать не может, а чтобы его научить, нужно было написать парсер запросов — так как критерии соединения должен содержать правильные алиасы. Оборачивание же части запроса в подзапрос тоже даром не проходит — стоимость запроса вырастает.

Я перебрал несколько решений, которые пришли мне в голову и остановился на следующем: в данный момент билдер создаёт временную «вьюху» с определённым именем, которое указывается в качестве источника запроса. Выглядит это так:

CREATE OR REPLACE TEMP VIEW некоеимя AS (
    -- тут у нас подзапрос
);
WITH RECURSIVE prior AS (
    SELECT … FROM некоеимя WHERE …некий критерий…
    UNION ALL
    SELECT … FROM некоеимя INNER JOIN prior …критерий соединения…
)
SELECT … FROM prior…

Выходит достаточно эффективно, но смущают две вещи: во-первых, всё это выглядит очень неизящно, во-вторых, для «вьюхи» нельзя подготовить план — все параметры приходится вставлять в запрос, так что максимальная производительность, естественно, не достигается.

Оставить комментарий

💰 Шалаш на острове сокровищ— 4

Сегодняшняя добыча (92.58КиБ)
Сегодняшняя добыча — результат многочасового труда

Сегодня мы побили все рекорды — выехали в половину шестого утра, а вернулись домой в седьмом часу. Обошли несколько домов, результат следующий: «конина», 2 копейки 1924 года (в отличном состоянии, но гнутые), 3 копейки 1946, пуговица братьев Бух царского периода, кольцо (вероятнее всего — «конина»), пуля, шток от умывальника, безымянная пуговица (думаю, современная), странный значок, маленькая пуговичка «Законъ» в плохом состоянии, капсуль от патрона, алюминиевый значок (кажется с Лениным) и пуговица с непонятным гербом.

Последнюю пуговицу не удалось опознать, кажется на ней герб какого-то города — два вертикальных колоса по краям, некий зверь на щите, остальное пока разобрать не смог.

Ещё была советская медаль «За доблестный труд», но её забрал себе владелец одного из домов, где мы искали и девять советских монет позднего периода в плохом состоянии, их я просто выбросил.

3 комментария

🐘 Подготовленные планы в PostgreSQL

Кто-то меня спрашивал о выгоде преподготовленных планов в «Постгресе». Наши испытания показывают, что выигрыш порядка 10—15%, что очень немало. И я уже рассказывал, что придумал рецепт как делить их в условиях «умирающего» ПХП.

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

Какой выход? Краткий ответ: пока никакой.

Самый очевидный — игнорировать такие ошибки. К сожалению, он не подойдёт — если ошибка произойдёт в транзакции, «Постгрес» её просто откатит. Второй выход — не использовать подготовленные планы. Я пока нашёл третий — мы используем планы только если уверены, что они пойдут на мастер — это запросы на изменение чего-либо.

С другой стороны у меня появилась идея — добавить в эскуэль конструкцию PREPARE IF NOT EXISTS, ребята из, с которыми я обсуждал эту идею, PostgresPro уже сделали несколько версий патча.

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

Очень надеюсь, что патч доведут до ума и мы скоро сможем его использовать.

19 комментариев

🏠 О стоимости квартиры в Москве…

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

— «Яндекс.Книга» (Дмитрий Соколов-Митрич).

Благословенные времена. Речь идёт о стоимости квартиры в Москве в Перестройку, насколько я понял из контекста книги. Брянская улица находится около метро «Киевская», очень недалеко от центра.

14 комментариев

🐘 «Синхронная реплика» PostgreSQL

Я в последнее время был очень сильно занят — мы переводили одну из наших крупных инсталляций документооборота на «Постгрес» (правда перевод самой крупной впереди, но у меня чувство, что мы будем ждать следующие версии).

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

На «Постгресе» мы, конечно, захотели аналога и, казалось, нашли его — pgpool-II, который разделяет запросы на пишущие и читающие, которые потом распределяются им на мастер и синхронные реплики.

Наши нагрузочные испытания показали, что на пиковых нагрузках синхронные реплики никакие не синхронные, оказалось, что «синхронность» реплики только в том она говорит мастеру «я всё приняла», когда данные попали на диск и именно в этот момент.

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

Это будет исправлено в будущей 9.6, а пока живём с тем, что есть.

6 комментариев

← сюда туда →