суббота, 30 июля 2022 г.

[life.audiophilia.diy] Переделка кабеля с 3.5mm на балансный 4.4mm штекер и использование его для самодельных 14.8mm вкладышей

Давно ничего не рассказывал про свое увлечение бюджетной аудиофилией. Да и особо нечего рассказывать. Многое перепробовал, некоторое мнение составил. Экспериментировать с доступными мне комплектующими и относительно недорогими ЦАПами уже не интересно, а на то, что еще хочется попробовать, пока нет средств :)

Но вот вчера решил закрыть сразу два открытых вопроса:

  • что делать с 3.5mm MMCX кабелем от NiceHCK, который уже больше года валяется у меня без дела. Покупался этот кабель когда-то под очень даже неплохие заушные мониторы Tiandirenhe TD2, но затем я все свои заушные мониторы распродал, а кабель остался. Кабель специфический: очень тонкий, очень гибкий, завязывается в труднораспутываемые узлы просто на раз-два. Зато очень легкий, практически невесомый. Плюс к тому я перешел на балансный 4.4mm разъем и старые небалансные кабеля с 3.5mm штекером мне уже и не нужны. Следовало бы его продать, но так как он изначально недорогой, да еще и б/у, то с продажей лень было связываться;
  • что делать с самодельными вкладышами с неплохим 14.8mm драйвером с титановой диафрагмой и импедансом 40ом. Вкладыши эти были собраны с несъемным кабелем больше года назад и отношения с этими наушниками у меня не особо складывались. После ВАУ-эффекта в первые пару дней показалось, что в них слишком мощные басы, способные продолбить дырку в башке. Потом, когда пытался слушать их без амбушюр вообще, стало не хватать детализации на верхах. В общем, всегда обнаруживался какой-то фатальный недостаток и наушники лежали без дела. Кроме того, кабель у этих наушников был небалансный 3.5mm, поэтому не было возможности послушать вкладыши с балансными ЦАПами.

Изначально было желание выставить на продажу и кабель, и вкладыши.

Но пару дней назад сравнивая свои основные 15.4mm вкладыши с LCP-диафрагмой с самодельными затычками с 10mm динамиком внезапно обнаружил, что мне перестали нравится басы на LCP-динамиках. В некоторых композициях, особенно с женским вокалом, звуки ударных как будто бы выходили на передний план и "забивали" своим буханием все остальное. Тогда как в затычках с 10mm динамиком такой проблемы не было, там на первом плане как раз был женский вокал, а басы оставались на заднем плане.

Мне стало интересно, а как себя поведут на этом же материале старые вкладыши с 14.8mm динамиком с титановой диафрагмой, там же басы были еще более ударными.

И, как это не удивительно, но 14.8mm динамики показали себя более достойно. Ударные мощные, но звучат чуть "дальше", женский вокал остается на переднем плане.

Захотелось переделать эти 14.8mm вкладыши так, чтобы их можно было использовать и с ЦАПами с балансным выходом. Тем более, что за время лежания в футляре установленный на наушники кабель загрубел и утратил эластичность, что не есть хорошо: явно рано или поздно где-то переломится и придется менять.

К сожалению, корпусов с MMCX разъемами под 14.8mm динамики у меня нет, а самостоятельно переделывать пластиковые под MMCX не хотелось, не очень эстетично выглядящий результат получается.

Еще одной неприятной особенностью имеющихся у меня корпусов под 14.8mm является то, что в них узкий кабель-канал. Только относительно тонкие провода туда можно засунуть.

Тут-то и появилась идея взять валяющийся без дела черный кабель от NiceHCK, заменить 3.5mm штекер на 4.4mm, срезать MMCX-контакты и использовать получившийся балансный 4.4mm кабель для переделки 14.8mm владышей.

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

Кому интересен небольшой фотоотчет, милости прошу под кат.

среда, 27 июля 2022 г.

[prog.c++] Немного разрозненной рефлексии на тему C++ и ощущения себя самого в мире C++ных проектов

За последние полтора-два месяца довелось погрузиться, наверное, в четыре разных C++ных проекта. На разную глубину, на разное время, с разными целями. Проекты, написаны разными людьми, в разное время.

Вынырнул, так сказать, из манямирка собственных проектов, оглянулся по сторонам , прифигел :)


Поймал себя на том, что мог бы работать C++ корректором :)

Это как в литературе есть редакторы, а есть корректоры. Редакторы отвечают за фактологическую и стилистическую составляющую, а корректоры отвечают за то, чтобы все было хорошо с точки зрения языка: орфографические ошибки, опечатки, знаки препинания и вот это вот все.

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

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

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


Самодокументирующийся код -- это миф.

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

Так что блин, комментарии нужно писать. Даже если сейчас они кажутся избыточной банальностью. Через 10 лет за любой комментарий в коде можно спасибо говорить, а уж если это адекватный и полезный комментарий, то хоть в ноги кланяйся :)

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


Думаю, что C++ для молодых разработчиков -- это бесперспективно.

Да, C++ никуда не денется и будет с нами еще не одно десятилетие. Но если тебе сейчас 20 лет и перед тобой открыты все пути (а уж тем более если ты вошел в ойти просто за зарплатой), то незачем тратить годы своей жизни на достижение мастерства в C++. Без которого, к сожалению, нормально программировать на C++ не получается. А если не нормально, то лучше и не надо.

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

А основная часть работы, связанная с C++, будет касаться сопровождение легаси. Т.е. разгребание чужого дерьма.

Оно вам реально нужно?

Оставьте C++ старперам, вроде меня. А там глядишь, и C++ станет не актуальным, т.к. все динозавры (включая и меня) вымрут. А место C++ постепенно займет что-то, что будет и приятнее в использовании, и безопаснее.


Если не считать тех небольших периодов, которые удалось потратить на выпуск новых версий SObjectizer, so5extra и RESTinio, все остальное время приходилось заниматься задачами, которые нужно делать, т.к. за них платят, но которые интереса или воодушевления не вызывают.

Поневоле задумываешься, а что именно мне самому хотелось бы запрограммировать?

Вопрос, как оказалось, далеко не праздный. С учетом того, сколько уже всякого разного за плечами, не так уж просто найти то, что вызывает однозначное "хочу!" Первое, что приходит на ум -- это отпуск месяца на три, чтобы в это время вообще никакого программирования :)

Если же говорить серьезно, то, наверное, я бы с удовольствием сделал бы свою реализацию HTTP. Хоть HTTP1/1, хоть HTTP2, хоть HTTP3. Все это пригодилось бы в том же RESTinio. Но, главное, этим было бы интересно заниматься мне лично.

Но поскольку денег это не принесет, а счета оплачивать как-то нужно, то... :(


Вообще жалко, что язык D не взлетел (еще более жалко, что он развивается именно так, как развивается). D версии 1.000 образца 2007-го года был языком, который для меня лично выглядел желанной заменой C++.

понедельник, 25 июля 2022 г.

[work;life] Послесловие к сказу про собеседования в Тинькофф

Не смотря на то, что пройти сквозь собеседования было интересно и, надеюсь, полезно, повторять сей опыт мне не хочется.

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

Как неоднократно говорилось, мой код лежит в OpenSource, найти и оценить его не сложно. Было бы желание. Ну а если желания нет, то зачем вам именно я? ;)

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

И да, ожидаемо, что в крупные компании, вроде Тинькофф, Yandex, Лаборатория Касперского, ВКонтакт, Сбертех и т.д., и т.п., где есть формализованные процессы найма и вот это вот все, меня с таким отношением не возьмут. Да и, по большому счету, одиночки-велосипедостроители, типа меня, там и не нужны.

Ну и ладно. Как по мне, то небольшим компаниям, которые не могут нанимать звезд масштаба Антона Полухина, я смогу принести больше пользы.

[work;life] Сказ о том, как я в Тинькофф шел, шел и не пошел

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

Преамбула

С прошлого года у нас есть заказчик из Западной Европы. "У нас" -- это у крошечной компании "СтифСтрим", в которой я соучредитель. После февраля 2022-го и начала санкций против РБ/РФ у нас начались приключения.

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

А спустя еще пару месяцев прозвучал набат: не смотря на то, что клиент нам деньги перечислил, дойти к нам они никак не могли.

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

Собственно, такое развитие событий просматривалось, поэтому я стал осторожно закидывать в блоге удочки с целью найти заказчиков из РФ или РБ. Сперва завуалировано, потом совсем уже прямым текстом, продублировав ссылку в Twitter.

Один добрый человек поделился этим твитом и тут-то все и завертелось.

Амбула

Твит попался на глаза менеджеру Тинькофф (первому из). Он спросил не желаю ли я пообщаться. Я пожелал и меня свели со вторым менеджером, после чего состоялось Zoom-встреча со вторым менеджером и руководителем одного из направлений разработки.

Рассказал о себе, о своем опыте, о ситуации в которой оказался и о том, почему нахожусь в поиске.

Полагаю, что произвел нормальное впечатление и мне предложили пройти по их стандартному пути найма: общение с HR, затем несколько собеседований, затем еще одна беседа о том, куда меня можно будет пристроить в случае успешного прохождения всех стадий отбора.

В общем, процесс пошел.

Пообщался с HR. После чего мне назначили первое собеседование, на котором оценивалось знание языка C++.

После первого собеседования состоялось второе, на котором уже оценивалось мое умение программировать и способность решать задачи.

Затем было еще и третье собеседование, посвященное т.н. system design.

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

Это должна была стать работа над OpenSource версией СУБД greenplum.

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

В итоге понял, что не хочу.

Другого проекта для меня не нашлось, так что в Тинькофф я не попал.

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

Немного о самих собеседованиях и моем отношении к происходившему на собеседованиях

Некоторой пикантности ситуации могло бы придать то, что сам я более чем скептически отношусь к такому методу отсева соискателей. Кроме того, мой код спокойно лежит в OpenSource, его можно посмотреть и сделать выводы о моем уровне. Если этого недостаточно, то можно было бы пообщаться по поводу какой-то из открытых разработок. ИМХО, разговор бы получился предметнее.

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

Большой проблемой представлялось то, что основной принцип онлайн-собеседований, а именно решение задачек здесь и сейчас, не отходя от кассы, -- это ну прям полная противоположность тому, как я привык работать.

Много лет я вообще программировал сперва на бумаге, а потом уже набирал код на компьютере. В последние годы так уже редко делаю, но все равно мне нужно сперва хорошенько подумать, порисовать каракули в тетрадке, набросать черновые кусочки будущего решения. Только после этого из каши в голове начинает выкристализовываться то, что должно быть воплощено в коде. Да и то, в процессе кодирования многое может кардинально поменяться.

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

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

Вроде как особых затруднений ничего не вызвало, но зато в очередной раз понял, что внимательность не сильная моя сторона. Ряд моментов должен был бы прямо броситься в глаза, но я почему-то их не заметил. Ну и да, здесь как раз нашлось место обсуждению виртуального деструктора* ;)

На первое собеседование отводилось 1.5 часа, мы чуть вышли за эти рамки, но это больше за счет разговоров о вопросах на собеседованиях по C++ и о сложности C++ вообще.

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

По мере сил постарался подготовиться: порешал что-то по вечерам (списки поразворачивал, ну и строку развернул заодно**). Даже на leetcode зарегистрировался и сделал там пару простеньких упражнений, чтобы почувствовать каково оно, писать код с места в карьер и сразу в Web-IDE.

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

В конце пообсуждали третью задачку. Запрограммировать решение времени не было, но там основной фокус был в том, чтобы придумать именно что алгоритм решения. Естественно, не придумал, но вроде бы на наводящие вопросы интервьюера отвечал :)

На второе собеседование отводился один час и мы за пределы этого лимита, если не ошибаюсь, не вышли.

Видимо, два этих собеседования я прошел нормально, поэтому меня допустили к интервью на тему проектирования систем, которое должны проходить претенденты на senior-скую должность.

К этому собеседованию я относился гораздо проще, чем двум предыдущим, ибо облажаться по первым двум не хотелось, как-никак больше тридцати лет в программизме и около 30 лет в обнимку с C++. А вот "проектированием систем", да еще и относящихся к Web-у, не приходилось заниматься уже лет 8 как. Так что нарастить здесь опыт за несколько дней было нереально. Поэтому, если к двум первым я еще пытался хоть как-то подготовиться, то перед третьим разве что прочитал несколько, как оказалось, бесполезных статеек в Интернете на тему "system design interview".

На собеседовании же я честно пытался разыскивать последние крупицы в скудных запасах общей эрудиции чтобы предложить хоть что-то отдаленно напоминающее рабочую схему. Плюс даже умудрился набросать схемки трех простеньких табличек в БД, хотя с РСУБД дел не имел уже лет 10, если не больше. Ну и на вбрасывания и замечания со стороны интервьюера, вроде бы, реагировал адекватно, хотя и тупил изрядно.

Третье собеседование также ограничивалось одним часом и мы в это время уложились.

По итогу от собеседований остались самые теплые и приятные впечатления, которые можно суммировать как-то так:

  • ожидал, что будет хардкорнее. Сильно хардкорнее. Скажем так, сам себя бы по C++ я бы срезал, даже не углубляясь совсем уж в тонкости языка ;) Ну и если бы пришлось инвертировать бинарное дерево, то мог бы выйти конфуз, т.к. я даже и не знаю, что это за операция такая, не дошел в самоподготовке до этой животрепещущей темы*** :)))
  • отличные впечатления произвели все трое интервьюеров. Приятно было общаться, чуствовалось, что ребята и грамотные, и понимающие, и внимательные. Никаких попыток самоутвердиться, ничего и близко похожего на желание как-то принизить соискателя или "докопаться до столба". Так что собеседования, для меня лично, напоминало спокойное и конструктивное общение коллег, работающих над общей проблемой, а не выяснение того, кто и чего стоит.

Немного о впечатлениях от greenplum

Для тех, кто, как и я, про greenplum раньше ничего не слышал, попробую резюмировать в двух словах: это сильно доработанный напильником форк PostgreSQL, который за счет архитектуры MPP (massively parallel processing) позволяет эффективно выполнять задачи OLAP (online analytical processing) на больших объемах данных.

Как я понял, доработан PostgreSQL в greenplum очень значительно. Что-то написано на C++ (вроде оптимизатора запросов), что-то на чистом Си (вроде собственного протокола общения между нодами).

Сам по себе greenplum существует в двух версиях: платной, с некоторыми дополнительными возможностями + поддержка от вендора, и бесплатной OpenSource-ной, доступной на GitHub-е. В связи с известными событиями вендор свою поддержку для российских компаний прикрыл, из-за чего и возникла потребность в доработках открытой версии greenplum своими силами.

Время, которое я взял на знакомство с greenplum, ушло на то, чтобы найти и прослушать несколько докладов о greenplum на YouTube, а также на то, чтобы попытаться посмотреть на код greenplum.

И чем больше я знакомился с greenplum, тем меньше мне нравилась идея вписаться в этот проект.

Во-первых, сама по себе тема СУБД для больших объемов данных и OLAP меня ну вот вообще никак не зацепила. Казалось бы десятки петабайт информации, кластера, нагрузка, все дела... А не торкает и все.

Ну вот бывает так, что предлагают какую-нибудь совсем дурацкую тему, вроде "А давайте забежим босиком на Эверест"****, и ты такой: "А давайте! Когда стартуем?" и с нетерпением ждешь отмашки.

А тут отличная жизненная и востребованная тема... И ноль эмоций.

Ну да, десятки петабайт информации. Ну да, кластера. Ну да, нагрузка. Но не торкает. Вообще.

Особенно грустно это было осознавать слушая очередной доклад по greenplum-у: у докладчика глаза горят, он полон энтузиазма и видно какой кайф он от своей работы получает. А вот тебя не торкает.

Во-вторых, я все-таки C++ разработчик. От использования чистого Си отказался давным давно, еще будучи студентом, о чем ни разу с тех пор не пожалел. Время от времени с чистым Си мне дело иметь приходиться, но в восторг это не приводит. Более того, я постоянно ловлю себя на том, что не понимаю, как нормально программировать на Си: вещи, которые на C++ очевидны и делаются с полтычка, на чистом Си превращаются в написание простыней кода, где за каждой строчкой приходится следить гораздо тщательней.

И вот мне предстоит вписаться в проект, значительная часть которого написана на Си.

Да и та часть, которая на C++, там весьма специфическая.

Сперва я нашел тот самый реализованный на C++ оптимизатор для greenplum пятой версии. Написан он на С++98. По следам первых впечатлений от кода оптимизатора на C++98 я даже маленькую заметку в блог закинул.

Правда, затем "Зоркий Глаз" заметил, что в шестой версии greenplum оптимизатор лежит уже прямо внутри исходников greenplum. И там уже C++14. Но, как я и предполагал, заметного эффекта переход на более свежий стандарт не дал.

Суть в том, что в этом куске greenplum-а чуть ли не своя маленькая C++ экосистема создана -- там очень много своего: свои контейнеры, свой менеджер памяти (по типу арены), своя система тасков и т.д.

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

Причем сам по себе C++ный код производит двоякое впечатление. С одной стороны, он нормально написан. Все читается, не встречается каких-то явных косяков, глядя на которые тебя передергивает. Достаточное количество комментариев, чтобы разобраться в коде. В общем, вполне себе хорошая кодовая база, ее авторам совершенно нечего стыдиться, скорее наоборот.

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

  • венгерская нотация. Да-да, она самая. Префиксы у имен типов и переменных. Если кто-то заглядывал в исходники MFC, то поймет о чем я. И если к именам классов/структур привыкнуть несложно, то вот способы именования методов и элементов перечислений (enum-ов) вымораживали меня гораздо больше;
  • странное проектное решение, при котором вроде как для контроля времени жизни объектов использовался счетчик ссылок (там даже базовый класс есть, от которого для этих целей нужно наследоваться), но при этом увеличивать/уменьшать количество ссылок в коде приходиться вручную (вот случайный пример метода, в котором AddRef и Release вызываются вручную). Что, как мне показалось, делает код менее C++ным, чем хотелось бы.

Поэтому чем больше я знакомился с исходным кодом greenplub, тем больше задавался вопросом о том, а хочу ли я на ближайшие несколько лет (а может и больше) застрять в этом маленьком завязанном самом на себя мирке потрохов PostgreSQL+greenplum? Да еще и заниматься поддержкой не только C++ного, но и чисто Си-шного кода...

И чем больше я об этом думал, тем меньше мне этого хотелось.

Тут ведь и еще один фактор сказывался: в последнее время у меня есть ощущение, что подзастрял в C++14 и C++17, что надо бы как-то заставить себя двигаться в сторону C++20. Если уж я не решаюсь уйти из C++ в какую-то более современную экосистему (вроде Rust-а или Go), то хотя бы в C++ нужно пытаться сильно не отстать. Ибо есть у меня ощущение, что C++20 разделит мир C++ на "до" и "после" не хуже, чем это сделал C++11. И лучше бы оказаться на той стороне, которая "после".

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

А вот глядя на C++ из greenplum и у меня было подозрение, что здесь многопоточность не нужна от слова совсем (я так понял, что код там принципиально однопоточный). Да и для самой простенькой шаблонной магии здесь вряд ли найдется место.

Короче говоря, мне показалось, что если уж оставаться в мире C++, то хотя бы в проектах, где нужно использовать современный C++ и где мой прошлый опыт в той же многопоточности окажется востребованным.

А greenplum не был похож на такой проект :(

На мой взгляд, конечно же. Вполне возможно, что я сильно ошибся.

Так почему же я все-таки отказался?

Основной причиной было опасение оказаться в "золотой клетке". Это когда тебе не нравится то, что ты делаешь, но ты вынужден это делать изо дня в день. А платят тебе при этом так, что ты не можешь решиться уйти.

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

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

Что касается самой задачи по развитию greenplum-а, то как мне кажется, она на ура зайдет следующим категориям разработчиков:

  • молодые специалисты, возможно вчерашние или даже действующие аспиранты, у которых реляционные СУБД являются предметом их научного интереса. Если тема РСУБД интересна, особенно специфика БД для OLAP, то это шикарный шанс поучаствовать в разработке одного из флагманских продуктов в данной нише;
  • разработчики, которые уже принимали участие в работах над СУБД (особенно если это что-то вроде PostgreSQL или MariaDB). Для них это будет привычный мир и привычные задачи;
  • разработчики солидного возраста, которые хотели бы спокойно доработать оставшиеся 3-5 лет до пенсии на хорошем проекте, с нормальным уровнем качества кода, с большим наследием, с отсутствием погони за модными и молодежными стандартами. Как по мне, так это именно такой проект: для спокойного и вдумчивого разбирательства, для тщательно продуманных изменений и дополнений, без необходимости насыщать код фишками из последних стандартов.

Вот только сам я ни в одну из этих категорий не попадаю.

Вместо заключения

Не смотря на то, что с трудоустройством в Тинькофф не вышло, впечатления остались самые положительные.

Во-первых, я впервые в жизни прошел через подобные собеседования.

Вот реально, никогда такого не было.

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

А тут тебе и собеседование на знание языка, и программирование в on-line. Хоть на себе прочувствовал что это такое.

Во-вторых, мне понравилось то, как в Тинькофф это устроено. Все четко, все по делу. Молодцы, решпект и уважуха.

PS. Забавный факт. Весной 2021-го года у нас была перспектива заказа на доработки MariaDB. Я тогда краем глаза заглянул в исходники этой самой MariaDB и чуть ли не сходу нашел мелкий баг. Зарепортил и его через какое-то время пофиксили. Сейчас краем глаза заглянул в greenplum и нашел мелкий баг :) Зарепортил (цынк), наверное пофиксят со временем.


* Это мем про уровень знания C++. Активно эксплуатировался в Рунете, в частности на RSDN.
** Еще один мем. Некоторые ыксперды в Интернетах утверждают, что большинство соискателей, претендующих на сеньорские позиции, не способны написать разворот списка или разворот строки.
*** Это о том, как автора homebrew не взяли в Google.
**** Отсылка к "Смертельный марш" Нортона.

воскресенье, 24 июля 2022 г.

[prog.flame] Если можно, то не спрашивайте меня про новый язык Carbon

Тут в наших Интернетиках разгоняется новый хайп вокруг экспериментального языка Carbon от Google.

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

Краткое впечатление: мне не интересно.

Складывается ощущение, что Google с Carbon-ом решает ту же самую проблему, что и Microsoft двадцать пять лет назад, когда ей не позволили форкнуть Java и "облагородить" ее нужными для Microsoft расширениями. Как говорится, у Java обнаружился фатальный недостаток, поэтому в Microsoft сделали C#.

Теперь вот Google обнаружил в Rust несколько фатальных недостатков. И пытается сделать Carbon, который вроде как и Rust, но с прицелом на дешевый интероп с C++ "искаропки", привычным многим ООП и чуть более щадящим синтаксисом.

Возможно, и с более низким порогом входа. Но об этом пока рано судить.

Мне, как старому C++нику, хочется иметь дело с очищенным от вековых наслоений C++. Т.е. привычный синтаксис, привычные возможности, легкая адаптация старых исходников под новый вариант языка.

Ну, например, стоило бы:

  • выбросить typedef;
  • выбросить старый синтаксис для объявления указатель на функцию;
  • выбросить старый синтаксис определения переменных (чтобы не было загадок из категории "как объявить массив указателей на массивы указателей");
  • выбросить унаследованные из чистого Си enum-ы (чтобы остались только enum class);
  • выбросить унаследованные из чистого Си вектора в пользу std::array;
  • сделать так, чтобы new возвращал не голый указатель, а экземпляр move-only типа std::owner<T>, а в delete можно было передавать только std::owner<T>;
  • отказаться от неявных приведений типов;
  • отказаться от [[nodiscard]]. Нельзя игнорировать возвращаемые значения. Когда же это можно, то следует ставить отметку [[maybe_unused]];
  • отказаться от SFINAE в пользу концептов;
  • отказаться от существующего механизма выброса исключений (когда можно бросать все что угодно, но принято разбрасываться наследниками std::exception) в пользу более эффективных исключений, где бросаются только экземпляры std::errc;
  • и т.д., и т.п.

Вот такой "очищенный C++" стал бы для меня заменой современному C++, а не этот Google-овский Carbon. Потому что если бы я хотел Rust-а, то просто взял бы Rust.

Пожалуй, это и все, что я пока могу сказать по поводу Carbon.

Посмотрим, что случиться с этим языком через несколько лет, когда он доберется до релиза версии 1.0. До тех пор не вижу смысла к этой теме возвращаться.

PS. Сильное впечатление на меня произвел вот этот пример кода. Такое ощущение, что кто-то хотел Ada-83 в синтаксисе Rust-а :)))

external impl like T as AddWith(like U) where .Result == V {
  // `Self` is `T` here
  fn Op[me: Self](other: U) -> V { ... }
}