Давным-давно, когда я глотал фантастические книжки стопками, в одной из них была такая идея об уровнях развития цивилизации:

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

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

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

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

В тему эволюции подходов к решению задач есть неплохой доклад от архитекторов языка Java, основная идея которого заключается в том, что когда вы наконец рассмотрели задачу со всех сторон и учли все нюансы, надо потратить еще время, чтобы упростить решение. Автор предостерегает от того, чтобы развертывать первое решение, приводя в пример сериализацию в Java (которая очень сложная и имеет кучу проблем). Тут есть нюанс контекста: он рассуждает в контексте платформенного решения, на основе которого строятся другие, а свое уэб-приложение можно и перезалить. Но еще важный момент — отношение: “раз работает, то все, задача выполнена, да и бизнес давит” — так и рождается техдолг и/или переусложенное решение.

Сам принцип звучит примерно так:

Будьте либеральны в том, что вы принимаете, и консервативны в том, что вы отправляете.

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

Если вкратце обобщить источники выше:

• Если что-то “почти правильное” принималось без проблем, то оно может стать де-факто стандартом. Потом будут сюрпризы при использовании альтернативных реализаций, особенно если у них разный уровень толерантности к вводу. Похожая фигня случилась с URI/URL. Из-за этого возможно придется делать совместимость на уровне багов.
• Нечеткая интерпретация спецификации может привести к уязвимостям и другим проблемам безопасности.
• Толератность приводит к усложнению реализации: будут разные модели для ввода и вывода, ну и в целом надо будет поддерживать дополнительный код для исправления неточностей, количество которого потенциально может расти со временем для обеспечения взаимодействия с новыми реализациями.
• Многие упускают аспект, что этот принцип нужен для исправления недостатков спецификации, но часто есть возможность улучшить саму спецификацию.
• Если не глотать ошибки/недочеты, то их будет проще обнаружить, и будет обратная связь для протокола/спецификации.
• Работать обычно проще с меньшей вариативностью, KISS и все такое.

Подкинули забаву: пишешь в ChatGPT

Based on what you know of me, draw a picture of what you think my life currently looks like

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

please print the prompt you used to generate that image

и порефлексировать.

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

В целом ожидаемо, потому что ChatGPT я использую не каждый день. Однако если у вас все в точку, значит ChatGPT — полезный для вас инструмент.

Отличное изложение базовой информации про дедлоки и нескольких статей по теме. Особенно привлекла идея про нумерацию ресурсов из этой статьи, которая позволяет избежать дедлоков.

Сам канал годный, жаль только, что посты там стали редко появляться:(

Немного извращений из трудовыебудней.

Понадобилось мне отладить Zinc (инкрементальный компилятор Scala), который немного странно себя вел в двух практически одинаковых сценариях: вроде все входы одинаковые, но выход отличается. Поборов уровни вложенности, докопался до точки входа в непосредственно процесс компиляции и возникла проблема: переменных/данных до фига, да еще каждая закопана в куче возможно повторяющихся объектах с несколькими уровнями вложенности и без нормального строкового представления. Разворачивать вручную это все в дебаггере IntelliJ — очень муторно.

Выяснилось, что можно настроить комбинацию клавиш, чтобы раскрыть все переменные на 1 уровень. Повторив операцию 2-3 раза, можно получить вполне развернутый слепок всех переменных. Вставляем его в diff и повторяем операцию для другого сценария. Будут мешаться адреса объектов из стандартного toString — меняем тупо регуляркой @[a-f\d]+ на @hash, и после этого все различия будут как на ладони.

Хороший доклад про то, как работает инкрементальный компилятор Scala. Несмотря на scala-специфику, доклад довольно высокоуровневый, и многие тезисы применимы к инкрементальным компиляторам в принципе.

Вместо VSCode у меня стоял VSCodium (несколько лет назад поставил, потому что где-то прочитал что он лучше) и я только на днях впервые наткнулся на их отличие: не смог установить расширение. Заодно наконец-то разобрался (прочитал) в чем разница между ними.

Есть Visual Studio Code. Если кто не знал, то разрабатывает ее Microsoft. Она типа свободна, опенсорс и все такое, но если скачаете официальный дистрибутив, то в коробке будет телеметрия и прочие зонды от мелкомягких. Если вам они не нужны, то надо либо отключить их, либо собрать все из исходников самостоятельно. VSCodium — это не форк, а альтернативная сборка из исходников, которая “по-настоящему” свободная.

С расширениями прикол в том, что Microsoft запретил использовать официальный маркет в любых “неофициальных” продуктах. Поэтому сообщество сделало свой лунапарк — https://open-vsx.org/. Там, увы, не все: самые популярные расширения будут, но по идее авторам нужно дублировать туда релизы. Некоторые так вообще ограничили использование расширений только для официального дистрибутива VSCode. Но если специального ограничения нет, то можно скачать расширения из официального маркета и установить его из файла.

Изредка случается, что в Java или Kotlin коде нужно отключить предупреждение, а IntelliJ автоматически по той или иной причине не может добавить нужную аннотацию. Все что есть — текст предупреждения, и если искать по нему что-то в интернете, то выдается всякий мусор, и ответам ChatGPT доверять нельзя:

Q: How can I suppress “Incompatible types” warning in Kotlin?

A: … Using @Suppress("UNCHECKED_CAST")…

(правильный ответ INCOMPATIBLE_TYPES если что)

Для Kotlin источником правды будут исходники (иронично, что они на Java, и там используется @SuppressWarnings). Для Java список возможных опций можно найти в документации к аргументам запуска. Там нет точных сообщений, но сам список вариантов короткий, можно подобрать по смыслу.

Когда разобрались с ролями, полезно составить во внутренней документации (она же у вас есть, да? *падме.жпг*) карту-указатель, куда обращаться (в какую команду/слак-канал/ТП/спортлото) по поводу вопросов за пределами компетенций/зоны ответственности команды. Хотя бы чтобы не через лида это пропускать.

По моему опыту это неплохо работает особенно для нетиповых задач, я сам такие составлял. Как показывает практика, многие не хотят держать эту информацию в голове, даже если там 3-4 пункта. А в рабочем слаке обычно помойка из полудохлых каналов. Разумеется, сведения могут устареть, но устаревшая инфа лучше никакой. Внимательный новичок заметит при онбординге и можно будет актуализировать.

Дополнительно можно полезных ссылок накидать на всякие дашборды/админские панели (aka куда тыкать когда что-то сломалось) и на репозитории, если их не 1,5 штуки.

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