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

Поскольку эта идея не очень оригинально, кто-то это уже сделал — consensus.app.

Consensus is an AI-driven search engine that specializes in extracting and condensing scientific insights from peer-reviewed sources. The goal is to democratize access to expert knowledge and make science more approachable.

Звучит отлично! Жаль, что не работает:

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

На нормальные вопросы я получал так себе ответы, которые не сильно отличались от “обычных” результатов поисковика.

https://www.freepublicapis.com/. В основном всякий мусор и что-то локальное, но есть и полезные вещи. Несколько примеров:

• API для сбора валидации e-mail
• API по вселенной Гарри Поттера
• Проверка, четное ли число
• Английский словарь — сам использовал в пет-проекте пару лет назад
• Картинки-заглушки
• Временные почтовые ящики

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

Сабж. В основном все советы годные и по делу.

Кто писал для JVM, встречался с Unsupported class file major version XX. Обычно это означает, что текущая версия java слишком низкая. Но какая версия нужна, например, для 55? Можно использовать табличные значения, но запомнить табличку или ссылку на нее — нетривиально. Проще воспользоваться формулой:

java_version + 44 = class_file_version

Если надо обновить свою фичу-ветку под новую базу, то это проще всего сделать с помощью

git fetch
git rebase <main-branch> --update-refs

Особенно это полезно, когда есть ветки от веток: update-refs рекурсивно обновляет все зависимые. На второстепенных ветках это приходится еще делать из-за того, что GitHub так себе отображает пулл-реквесты не от мастера.

The Culture Map — довольно известная книга про то, как отличается рабочая культура разных стран. Пересказов в интернете полно, например 1 или 2, все можно свести к 8 шкалам.

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

Примеры, основанные на нациях, скорее вредны. Да, может и есть особенности культуры, которые более часто встречаются в той или иной стране, но многие могут ошибочно воспринять, что именно так и будут вести себя ВСЕ люди оттуда. Даже с учетом того, что у меня не такой уж большой круг коллег со всех работ, и большинство, разумеется, из России, я видел много примеров характеров со совершенно разными оценками по этим 8 шкалам. И иногда со своими старшими родственниками мы общаемся в принципиально разных “культурах”.

Вообще эти шкалы — это как с “типами” людей, со всеми их недостатками. Однако про книжку знать скорее стоит, ее (пересказ) можно использовать как один из источников вдохновения для осмысления инженерной культуры в команде.

Довольно подробная статья, в которой про это рассказано.

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

Сами проблемы обозначены на 13 минуте (до этого идет слишком затянутое введение) и на 41-ой. Вкратце:

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

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

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

Еще докладчик посетовал, что автонастройка RDS от AWS толком ничего полезного не делает.

В конце было хоть что-то связанное с МЛ — оказывается, если спросить совета у ChatGPT по настройке БД, то он мало чего путного посоветует (как неожиданно).

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

• воспользоваться командой paplay с каким-нибудь звуковым файлом из /usr/share/sounds,
• “сказать” очень машинным голосом что-то через espeak,
• послать уведомление с помощью notify-send.

На маке это будут соответственно:

• afplay /System/Library/Sounds/Submarine.aiff,
• say lerolerolerolerolero,
• и ужасный osascript -e 'display notification "how hard it can be"'.

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

Вкратце — никому особо не нужны графические свистелки-перделки для написания кода: текст достаточно выразителен, куча инструментов уже готово, рутину убирает IDE. Однако очень полезны всякие штуки, чтобы показывать верхнеуровневые вещи: связь модулей/сервисов между собой, расположение кода в памяти, последовательность обмена сообщениями и т.п. Перекликается с докладом про интерактивное программирование.

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

А касательно интерактивного программирования — тут лидируют Excel и питоновские ноутбуки, где обновления будут практически мгновенными; ну и на фронте можно большую часть вещей делать в WYSIWYG режиме (особенно если включен live-reload).