🔑 Мастер ключей
Это Главный ключ страны, мы называем его «Ключ № 1 СССР». Он от входной двери в Мавзолей.
Согласитесь, что мне было бы очень трудно объяснить следователям КГБ, зачем и с какой целью я срисовал этот ключ в масштабе 1:1, если бы меня поймали за этим занятием.
Но к счастью, мне удалось сделать это незаметно, а поскольку срок давности за это преступление давно истёк, я предлагаю читателю полюбоваться на этот ключ. Правда же, он очень красивый?
Цитата из книги «Байки старого телемастера» Геннадия Гендина. Очень и очень рекомендую книгу, совершенно роскошная, читается на одном дыхании. Будет интересна буквально всем своими уникальными деталями советского быта — по роду работы автор был вхож в дома многих советских деятелей и даже в Кремль. Ключ, которые вы видите выше, он срисовал именно там.
👁 Глаз следящий
Обновилась до версии 2.9 моя любимая
Протокол довольно простой:
ESC ] 1337 ; File = [необязательные параметры] : изображение в формате base64 ^GРешил немного с ним побаловаться, результат на скриншоте — небольшая программа на «баше» — глаз, который следит за указателем мыши.
Пришлось разобраться с тем как вообще получают координаты мыши в консоли, плюс вспомнить школьную геометрию. Синусы, косинусы, вот это всё, неявно вычисляются через awk и используются для определения где нужно рисовать зрачок.
Чем дальше курсор находится от глаза, тем больше событий мыши получает консоль во время перемещений по окружности вокруг него.
Для запуска требуется iTerm2 2.9 и выше и Imagemagick.
💰 Шалаш на острове сокровищ—2
Сегодня постарались целенаправленно поискать монеты по домам. Жилой дом не порадовал буквально ничем, а вот бывший сельский магазинчик принёс 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 года.
🌀 Мельница в селе Симетбаш
Проезжали с приятелем через село Симетбаш, взгляд привычно зацепился за явно дореволюционную постройку. Пошли смотреть, издалека казалось — либо церковь (которой там быть не должно), либо мельница.
Вблизи ощущение старины постройки усилилось — кованые элементы, восьмискатная крыша. Но здание оказалось заперто, пришлось лезть на крышу — я заметил, что у окна выше не хватает стекла.
Фото выше делал на просунутый в окно фотоаппарат. Это действительно оказалась мельница, с электрическим приводом. Причём действующая до сих пор — к ней подведено электричество.
Гугление ничего не дало, поэтому решил написать в блоге — вдруг кто опознает постройку и расскажет её историю.
💰 Чистка монет: «никель», ранние «советы»
Вообще монеты я до этого не решался чистить — у меня тут нулевой опыт и я очень боюсь их испортить,
Начал с «никеля», их я нашёл в свой последний выезд. Посмотрел несколько роликов, прочитал несколько рецептов, выбрал один — монеты погружаются в уксус (в моём случае это был 5% раствор) с поваренной солью, а потом дочищаются содой.
Превосходный рецепт, всего за несколько часов довёл монеты до состояния выше. Не надо пугаться, это общая длительность процесса — изредка я наведовался в ванную, чтобы посмотреть как идёт, доставал монеты пинцетом, мыл, чистил и кидал назад.
Учитывая их первоначальное состояние, результат великолепный.
🏠 Кирпичи из дома Микляева (Михляева)
Сегодня повторно побывал в Доме Микляева, там вовсю идёт реставрация, за которой очень интересно наблюдать. В частности, к кирпичам «МЧ» добавились другие, с более интересными клеймами.
Клеймо Марии Челышевой, владелицы кирпичного сарая при деревне Малые Клыки в конце 19 века мне попадалось на левом углу дома, в этот раз я разглядел его и справа. Этих кирпичей вообще там много, видимо дом неоднократно ремонтировался.
А это уже
Другой новичок носит клеймо завода, принадлежавшего крестьянину Ивану Афанасьевичу Костину. В 1862 году он основал гончарный, изразцовый и кирпичный заводы в Нижнем Новгороде. Впоследствии был основан «Торговый Дом И.А.Костин с племянниками», кирпичи с клеймами которого попадаются в интернете.
💰 Шалаш на острове сокровищ—3
Сегодня весь день посвятили «охоте» в домах, в предыдущие выезды это не было основной целью. Обошли несколько домов, в том числе в одной из заброшенных деревень, которая оказалась, без преувеличения, разграбленной — полы вскрыты, всё что можно — выкопано.
Мы, естественно, полы не вскрываем, а просто ищем дома, где время или предприимчивые соседи постарались до нас. В этот раз добыча очень разнообразная.
Сверху и снизу — медные цепочки, скорее всего два обрывка одной более длинной.
В первом ряду — пять копеек 1911 года, 10 копеек 1914 (моё первое монетное серебро!), крышка от небольшого графинчика, свинцовая пломба (думаю, советских времён, на одной стороне «Т», на другой —
Во втором ряду — ранние советы (поздние фотографировать не стал). Это одна копейка 1935 года, и две копейки 1945, 1946, 1949 и 1956 годов.
Некоторые монеты пришлось серьёзно почистить. Проще всего было с серебряной — опустил несколько раз в специализированное средство «Аладдин» и монета чистая, а когда я её подбирал, она была такой тёмной, что я перепутал её с советской.
«Советы» я сначала сварил в соде, чтобы убрать зелёные наросты (наверное это медный купорос), потом положил в уксус, чтобы уменьшить красноту после соды и в конце почистил
🐘 «Рекурсивные» запросы в PostgreSQL
Одна из главных бед «Постгреса» — бедные (по сравнению с «Ораклом») «рекурсивные» запросы. Подробнее об этом
Если вы знаете рецепт лучше, поделитесь, пожалуйста.
Как я уже рассказывал, поскольку продукт у нас мигрирует с «Оракла» на «Постгрес», мы сейчас живём сразу на двух базах и некоторые виды запросов строят унифицированные билдеры.
Есть такой и для «рекурсивных» запросов. Нередко «рекурсивный» запрос приходится строить, выбирая не из таблицы, а из подзапроса. Наш билдер был устроен таким образом, что подобный запрос он строил по следующему образцу:
WITH RECURSIVE prior AS (
WITH virtual AS (
-- тут у нас подзапрос
)
SELECT … FROM virtual WHERE …некий критерий…
UNION ALL
SELECT … FROM virtual INNER JOIN prior …критерий соединения…
)
SELECT … FROM prior…Ну вот
Эффективнее оказалось убрать внутренний 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
Сегодня мы побили все рекорды — выехали в половину шестого утра, а вернулись домой в седьмом часу. Обошли несколько домов, результат следующий: «конина», 2 копейки 1924 года (в отличном состоянии, но гнутые), 3 копейки 1946, пуговица братьев Бух царского периода, кольцо (вероятнее всего — «конина»), пуля, шток от умывальника, безымянная пуговица (думаю, современная), странный значок, маленькая пуговичка «Законъ» в плохом состоянии, капсуль от патрона, алюминиевый значок (кажется с Лениным) и пуговица с непонятным гербом.
Последнюю пуговицу не удалось опознать, кажется на ней герб
Ещё была советская медаль «За доблестный труд», но её забрал себе владелец одного из домов, где мы искали и девять советских монет позднего периода в плохом состоянии, их я просто выбросил.
🐘 Подготовленные планы в PostgreSQL
Но вот какая неприятность — при подключении любого балансировщика нагрузки, совершенно неочевидно куда улетает ваш план и таблица в приложении не помогает — она единая, а серверов может быть несколько, у каждого свои планы подготовленные. Если мы начнём подготавливать его заново, а он уже есть, получим ошибку, что план уже существует.
Какой выход? Краткий ответ: пока никакой.
Самый очевидный — игнорировать такие ошибки. К сожалению, он не подойдёт — если ошибка произойдёт в транзакции, «Постгрес» её просто откатит. Второй выход — не использовать подготовленные планы. Я пока нашёл третий — мы используем планы только если уверены, что они пойдут на мастер — это запросы на изменение
С другой стороны у меня появилась идея — добавить в эскуэль конструкцию PREPARE IF NOT EXISTS, ребята из, с которыми я обсуждал эту идею, PostgresPro уже сделали несколько версий патча.
Основа идеи — всегда слать запрос на компиляцию плана, но если он уже был скомпилирован, ничего не делать. Мы его уже погоняли (оттуда и цифры первого абзаца), но на этом пути больше трудностей, чем себе можно представить — в частности, надо патчить ещё и продукты для балансировки и расширять его клиентский протокол.
Очень надеюсь, что патч доведут до ума и мы скоро сможем его использовать.
🏠 О стоимости квартиры в Москве…
Собственная квартира на Брянской улице, кстати, обошлась Воложу по цене двух американских персоналок общей стоимостью 3800 долларов. Техника в то время стоила дорого, а квартиры дёшево: рынок недвижимости ещё толком не сформировался. Квартиру можно было и за видеомагнитофон купить.
— «Яндекс.Книга» (Дмитрий
Благословенные времена. Речь идёт о стоимости квартиры в Москве в Перестройку, насколько я понял из контекста книги. Брянская улица находится около метро «Киевская», очень недалеко от центра.
🐘 «Синхронная реплика» PostgreSQL
Я в последнее время был очень сильно занят — мы переводили одну из наших крупных инсталляций документооборота на «Постгрес» (правда перевод самой крупной впереди, но у меня чувство, что мы будем ждать следующие версии).
Много любопытного я узнал об этой СУБД, возможно
На «Постгресе» мы, конечно, захотели аналога и, казалось, нашли его —
Наши нагрузочные испытания показали, что на пиковых нагрузках синхронные реплики никакие не синхронные, оказалось, что «синхронность» реплики только в том она говорит мастеру «я всё приняла», когда данные попали на диск и именно в этот момент.
Когда нагрузка близка к пиковой, данные физически на диске есть, а логически они ещё не считываются. То есть это скорее пригодно для того, чтобы в случае смерти мастера быстро поменять его на реплику, чем для схемы с распределением нагрузки.
Это будет исправлено в будущей 9.6, а пока живём с тем, что есть.