elglin

Разбираю тут потроха не имеющей аналогов терраформовской кодобазы.
ТОННЫ ДИЧАЙШЕГО ХАРДКОДА.
При этом в лучшем случае абаснуй примерно такой: "Ну это у кого-то когда-то работало, а дальше все копипастили, не задумываясь". В худшем случае нет и этого.
Ну его нахер, ребята, так работать. Но именно так и работаем, потому что человека, который что-то понимает в программировании не на уровне кричания лозунгов DRY, KISS и так далее, а на уровне понимания их, найти сложно. А товарища, который под этими лозунгами будет бездумно копипастить (в кодовой базе около трехсот "почти одинаковых" файлов, из которых выделяется несколько кластеров одного размера, но есть и десятка три "снежинок"), найти очень просто.

Ну и еще. Любой вспомогательный скрипт, с моей точки зрения, должен выдавать машиночитаемый формат. Либо CSV/TSV/DSV, который awk-ается, либо JSON/YAML/TOML/XML (последнее, конечно, не нужно, но можно), который парсится тем же питоном (или jq для адептов баша) и кем только ни. При этом в идеале надо бы выдавать объект языка Х, который только в самом конце превращать в текст, чтобы желающий на том же языке привязаться не извращался конструкциями вида json.loads(json.dumps()). Желающий красивого вывода может написать обертку этого дела с форматированием - классическое отделение данных от представления.
Но нет. Только человекочитаемый вывод в формате, который **нешься парсить, не говоря за грепать.

Радует только одно. Сегодня тяпница, и эликсир узбагоения уже ждет.

Хочется писать хороший код. Продуманный. Отлаженный. Самое главное - хорошо спроектированный.
Проблема только в том, что, обычно, вокруг ходит цейтнот. Причем такой цейтнот, что с той стороны контроль классический, а у тебя блицевый. Тут, увы, не до анализа вариантов в схевенингенском варианте сицилианской защиты.
Это я к тому, что я сегодня осознанно вмерджил к себе кусок совершенно потрясающего говнокода. Задача-то банальная - отсыпать нотифайки в такую-то ручку в таких-то случаях. Проблема в том, что ручка же черт знает где, а поэтому все прелести распределенного программирования налицо.
Короче, я просто вогнал еще одну таблицу, куда эти нотифайки разного рода инсертятся. Потом наговнякал еще один воркер (у меня их с десяток, одним больше, одним меньше), который ходит в эту табличку и пытается слать. SELECT FROM notifications ORDER BY notification_id LIMIT 1 FOR UPDATE; получилось - DELETE FROM notifications WHERE notification_id = XXX; не получилось - а ничего не делаем, на следующем проходе поретраим и так ad infinitum. Да-да, никакого вам ограниченного ретрая с экспоненциальным отступом - ручка будет страдать, один хрен она не моя.
По уму надо тут просто что-то, умеющее pub/sub прикрутить, от кафки до амазоновского SNS. Но у меня был постгрес, приклад с воркерами и час времени, набранный кусками по 15-20 минут.

Вот так и живем, мать его так.

Мне несколько раз с интервалом от месяцев до лет снился сон на одну и ту же тему, что я второй раз учусь у себя на факе. При этом я осознаю, что учусь второй раз, и, вроде как, непонятно, зачем, но вот учусь. Ну и мысли (все во сне), что как же я сессию сдавать буду, у меня же работа, отпрашиваться надо будет и все такое.
Это я, собственно, к чему. Есть некая девочка, назовем ее Х. (нет, не Хуанита). Девочка учится на программистском факультете. Девочке я до того пытался нести в мозг матан и алгебру, их она сдала.
А вот теперь она попросила помочь с пересдачей по погромированию. Я сначала машинально (девочка позвонила аккурат между двумя нервными совещаниями) попросил прислать все задачи и вопросы, и только потом отметил, что на дворе не то, что февраль, а середина его, и сессия закончилась не только сама, но и вместе с пересдачами. Сталбыть, девочка не то, что с хвостом, а в одном шаге от пресловутого компота.
Ну ладно, слава яйцам, у нее не Паскаль, который я бы без методички не вспомнил (хотя у меня на нем написан один курсач - не мой, и одна лаба - не моя), а старый добрый Це. Ну на Це мы могем, и у нас, естественно, есть муха гэцеце (прольем скупую слезу над безвременно почившим ваткомом, а какой был в свои годы компилятор, какой был слон, какой был слон).
Понятное дело, что ничего эпичного там не было - немного очень простой строковой работы, набившие оскомину фибоначчи и немного работы со связным списком и деревьями (рекурсия, омномном). Ну, короче, один вечер после реально упоротой трудовой недели - могу, значит, еще, на первом курсе учиться.
Девочка то ли гнет дерево не по себе, то ли не познала мантру, что ИТ - это ноулайферство, но в консерватории надо что-то менять. Не мое, впрочем, дело ее жизни учить.

Но фиг с ней, с девочкой, там был интересный вопрос, который я в полубессознанке сделал через жопу, а хотелось красиво. Есть у нас два отсортированных бинарных дерева, нам надо найти мощность пересечения, и нам даже гарантируют, что элементы внутри каждого дерева уникальны.
Вариант через жопу - это пройти одно дерево насквозь и поискать каждый элемент в другом. Были бы это два массива, я бы параллельно по ним прошелся и за один проход все нашел.
Но это деревья, и по условиям задачи (структура данных задана жестко) указателя вверх у нас нет, только налево и направо. В этой ситуации я знаю, как сделать параллельный обход, имея два стека. Но у меня не плюсы, где я взял бы стек из STL и горя не знал, а голая сишка. Писать на автопилоте динамический стек поверх связного списка - ну, это так себе затея в первом часу ночи.
А есть ли более кошерный вариант? Теория-то уверенно говорит, что дерево в глубину без стека не обходится.

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

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

Вот я и думаю, прав ли я со своим физзбаззом. С одной стороны, любой человек, умеющий придумать и запрогать алгоритм, должен суметь в физзбазз. Но, может, сейчас это уже излишне? Может, стоит попуститься и не мучать людей задачей на один цикл и три if-а? Может, сейчас уже всякие фреймворки дошли до того, что можно писать годный работающий код и вообще не мучаться вопросом, как что-то сделать?
С другой вот стороны, как только ты начинаешь решать какую-то задачу сложнее, чем "пять строчек шелла", то у тебя сразу начинают вылезать конечные автоматы, очереди, графы, структуры данных и вся прочая унылая, но нужная теория из соответствующих курсов. Помню, было очень обидно изобрести jump table чуть раньше, чем про нее прочитал.
Вот и сижу я такой умный в когнитивном диссонансе.

В длинных спорах о том "каким ЯП учить в самом начале" с большим отрывом лидируют концепты "меня так учили" и "я на этом прогаю". Есть еще распиаренная лурком цитата: "Хороший программист обязан знать C". Попробую выпрыгнуть из этого концепта.
Итак, первый язык. Товарищи, на каждого рафинированного программера (вроде большей части дискутирующих) наберется пяток людей вроде меня, которые активно прогают, но далеко не рафинированные программеры, и десятка полтора-два людей, которым надо прогать, но от случая к случаю, как приложение к основной работе (бухгалтер, статистик, тысячи их). Поэтому порог входа должен быть низким, и (школа же, дети же) должен быть практически немедленный выхлоп, желательно наблюдаемый.
На мой личный взгляд, вариантов, собственно, три: VB.NET (да, бейсик), JavaScript и, да, он самый, несправедливо нелюбимый и оболганный Python. На первом можно за час-два собрать гуевую утилиту и за день написать виндовую игру класса "артиллерия", на втором можно нарисовать что-то динамичненькое в вебе за то же время; питон в этом плане менее гуев и чуть более задротский, но вот все-таки за него широчайший спектр применения, килотонны библиотек и вся прочая экосистема.
Циклы, условия и массивы есть, процедуры есть, ООП есть, хорошая работа со строками есть. Что еще надо, чтобы достойно встретить старость. На выходе мы имеем возможность объяснить, зачем вообще программировать, показать, что можно сделать дендрофекальным методом и кодом, заложить базовые концепты. Не факать мозги тем, кому это совсем не надо, но заложить какую-то базу для тех, кому это зачем-то потом понадобится, чтобы шурупы в мозг закручивались не по целине, а по старым следам. Кроме того, во втором и третьем (имхо и в первом, просто область специфическая, кто писал эксел-макросы, тот поймет) случае язык имеет некую ненулевую ценность и сам по себе.
Если говорить о втором языке - то это уже явно для тех, кто хочет связать жизнь с проклятыми ИТ, то есть программеров на ставку или полставки. А вот здесь уже нужно поднимать вопросы об эффективности, о-нотации, структурах данных, серьезном ООП, мультипоточности и что там еще - универский уровень, в общем-то. Более кровавый вариант - это С, менее кровавый - Go; альтернатива с бизнес-ориентацией - Java. Есть новомодный Rust, но я его не трогал вообще.
Теперь о плюсах. Я бы сказал, что плюсы - это идеальный третий язык. Я въезжал в него два раза, один около 2003, второй в 2019 - это заняло немало усилий и времени при том, что в первом случае это был мой пятый язык (Basic, Pascal, C, Java), а во втором - шестой (+ Python, и это не считая баша и повершелла). Плюсы офигенны, не спорю, но STL+Boost, на мой взгляд, доступны только для человека, который хорошо знает, зачем и почему ему это надо. Именно поэтому, на мой взгляд, плюсам нет места в общеобразовательной программе. Это магистратура или аспирантура - ну, по состоянию на 2020 год.

Я помню, что их три, и примерно два дня до собеса и два дня после помню, что какая значит. Помню, что суть в том, что все хранится один раз и именно там, где надо. Дальше у нас идут отношения 1-N, 1-1 и N-N, и как рубить второе с помощью вспомогательной таблицы (обычно поясняется на классическом примере авторов и книг).
Вся вот эта схематизация данных (равно как и строгая типизация в ЯП, но я отвлекаюсь) помогает, в том числе, заострить внимание на ценности данных. Что это самое важное во всей системе. Интернет, до кучи, изобилует историями о том, как пришедшую к успеху систему на какой-нибудь несхематизированной MongoDB потом приходится долго и нудно схематизировать, а то и переводить на какой-нибудь замшелый постгрес, потому что консистентность и производительность.
Но о чем, на самом деле, я. Вот у нас есть облако (AWS в данном случае). У него есть регионы. У нас есть приложения. А еще есть окружения вроде dev и prod. Между этими сущностями (регион, объект, приложение) отношение N-N везде, да еще и с необязательной принадлежностью. Еще аккаунт можно приплести, он тоже перцу добавляет.
В этой ситуации, когда нам надо собрать из всего этого рабочий конфиг, так и стоит действовать. Распиливаем все по сущностям, делаем наборы конфигов для аккаунта, окружения и там все такое, после чего это программно комбинируется аналогом SELECT * FROM a INNER JOIN b ON xxx INNER JOIN c ON yyy;
Да, сложно. Да, неинтуитивно. Но зато если ты давеча переименовал какую-то мелкую хрень, она у тебя переименовалась везде, где надо.

Но это, как выяснилось, не наш метод. Делаем иерархическую структуру папочек: регион-приложение-окружение. Ну ладно, общие настройки на регион наследуются, потому что терраформ умеет find_in_parents(). Ну а дальше у тебя столько полноценных конфигов приложения, в скольких регионах оно запилено. И еще хлеще с окружениями. Да, я понимаю, что те же коннстринги и все такое будут уникальны для каждого приложения... хотя темплейтинг вроде postgresql://{{app_user}}:{{app_password}}@{{env_psql}}:{{env_port}}/{{app_db}} это решает чаще, чем казалось бы.
Но нет. В итоге колоссальный объем самоповторений, репликация пусть коротенького, но одного и того же скрипта в 100500 экземплярах (что сразу делает его навечно неизменяемым, пусть он и написан через Ж).
Короче, я не могу понять, как до этой архитектуры доходили люди с сертификатами, катающиеся на re:Invent и занимающиеся Амазоном сильно дольше меня.

Возможно, они просто ни разу не работали с СУБД.

Обнаружил для себя полезное свойство интереса к истории.
Вот у вас есть система ввода и обработки заказов, особенно если это реальный хайлоад, и она обмолачивает от сотен до сотни тысяч запросов в секунду, а каждый запрос обрабатывается за время от секунд до минут.
Представьте себе, как это бы выглядело в 19 веке. Что приходит вам из какой-то деревушки письмо: "прошу выслать мне керосиновую лампу и три бочки керосина". Вы пишете служебную записку на склад: "прошу зарезервировать для г-на У. лампу и три бочки керосина"; наутро вам приносят ответ: "Все найдено и зарезервировано" - и вы пишете уважаемому господину У., что у него есть неделя на то, чтобы оплатить два фунта, семь шиллингов и три пенса почтовым переводом. И так далее.
По сути, в этом нашем ойти происходит все то же самое, только намного большим потоком и быстрее. А так можно перемасштабировать задачу в ситуацию, которая легко осознается человеческим мозгом. А если учесть, что время было неспокойное, а люди бардачные, и все вот эти служебные записки и письма регулярно терялись или доходили с опозданием, то сразу сильно проще понимается, где нужно поретраить, где поставить таймаут и все такое.
Полезное это дело, короче. А если представить, что вместо вебхендлеров у вас сидят гремлины за конторским столиком, то получается практически Пратчетт.

В каждом языке, я думаю, есть свой brainfuck на эту тему. В Сях есть классическое a = b++; , которым пугают на первых занятиях, в питоне есть нюансы, что "если у тебя тупл из списков, то элементы списков можно менять".
Вчера напоролись на очередную идиосинкразию поша. Логика системы, не вдаваясь в подробности, требует взять файлик и кинуть его в ручку.

with open('file.txt') as fin:
    send_to_rest_handle(json.dumps({'data': fin.read()})) # The file is at most 20K

Ручка, естественно, валидирует ввод, и при десериализации очень хочет, чтобы data было str и никаких.
И тут казалось бы аналогичный код с винды начинает валить четырехсотки, причем именно валидацией.
Виндовый код был, казалось бы, настолько же прост:

Send-ToRestHandle -Data (@{"data" = (gc -raw 'file.txt')} | ConvertTo-Json)

И вот если вы наивно проверите тип того, что вам даст gc -raw, то это будет String!

> $foo = gc -raw file.txt
> $foo.gettype()

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     True     String                                   System.Object

А потом просто посмотрите, как этот якобы String сериализуется. Ни черта это не String, это пол-таблицы Менделеева. Правильный ответ: (gc -raw 'file.txt').value.

И в чем тут парадокс. Неплохой язык пошик, и я как-то писал, что если бы в линухе запилили python-shell, то он был бы не менее идиосинкразиен. Проблем здесь две:
1. "Интуитивно-неинтуитивное поведение".
2. За счет объектной модели, конвейера объектов и вот этого всего некоторые простые вещи делаются сложно. И вот на фоне баша, питона и даже Сей, где задача почитать-пофильтровать-пописать очень интуитивна, пошик именно в этом компоненте грустен.

Дернул меня черт вставить в фикстуру сборки тест-кейсов команду `len(test_array)`
198 получилось, это вообще нереально руками проверять. Писец ручному тестированию.

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