Хороший паттерн для идентификации пользователя — должно быть три компонента: приватный id в базе (обычно UUID или число), идентификатор для логина (например, почта или какой-нибудь социальный логин) и публичный идентификатор (имя, или @name). Первый — постоянный, неизменный и, в идеале, никому (даже пользователю) не видный. Второй — личное дело пользователя и не должен быть виден другим, а id базы с ним связан как один ко многим.

Все это еще полезно с точки зрения ИБ: немного базы можно посмотреть в этом докладе. А еще можно почитать про курьезные случаи, из-за которых надо еще и ограничивать возможные варианты публичных идентификаторов.

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

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

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

Что делать? Давайте спросим ChatGPT 🗿

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

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

Подобные тезисы можно увидеть у астрофизика, который в том числе отмечает системные проблемы в науке; математика, который отмечает, что тяжело научиться доказательствам, если самостоятельно не пытаться; и мейтенеров zig, которые забанили LLM, потому что им пофиг на то, что PR не вылизан до блеска, главное, чтобы сообщество контрибьюторов, которые что-то понимают в коде, росло.

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

Одно из следствий сложности процесса — его тьюринг-полнота. На шрифтах можно даже LLM запустить.

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

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

Стали разбираться — эволюция базы повисла на переименовании таблицы. Сервис — монолит, кроме него в базу только метрики ходят (но не в эту таблицу). Однако переименование таблицы — это действие, которое требует ACCESS EXCLUSIVE лок, и ни одна операция, хоть как-то трогающая таблицу, не может выполняться параллельно.

“Убийцей” оказалась IntelliJ Idea Ultimate, в которой коллега запускал проверки на проде перед деплоем. На препроде воспроизвести не удалось, но при повторном деплое опять “все повисло” и только когда прибили Idea, все накатилось. Судя по всему, она запрашивала метаданные для автодополнения и т.п. и где-то висела незакрытая транзакция. psql такого бы себе не позволил (по умолчанию, по крайней мере) :/ А вообще еще лучше никаких лишних открытых соединений не держать при накатке изменений.

Как-то совсем мимо меня прошло, что LinkedIn вырос из им же созданной Kafka и сделал новый брокер сообщений/логов — Northguard.

Причина довольно прозаична: контроллер хранил довольно большое состояние централизованно на 1 узле и это в масштабах LinkedIn стало бутылочным горлышком. И это с учетом того, что от Zookeeper отказались еще в 2021. А еще были проблемы с балансировкой и обслуживанием тьмы кластеров. Продумали и миграцию, за это отвечает Xinfra — по сути, адаптер, поддерживающий оба брокера.

Один из популярных аргументов вайбкодеров заключается в том, что с ИИ мы просто переходим на более высокий уровень абстракции: сначала был машинный код, потом появились языки низкого уровня, затем высокого, фреймворки и т.п. И, мол, вы же не читаете вывод компилятора в машинных кодах? Тогда и код, выплюнутый нейронкой, читать не надо. Если что — с ее же помощью потом и исправите.

Однако с этим аргументом есть несколько серьезных проблем.

Первая — запись намерения. Для совместной работы над программным продуктом используют текущий уровень абстракции — если, например, это код на питоне, то у вас в репозитории, пул-реквестах и т.п. фигурирует конкретный код на питоне, а не какой-то его продукт, например, байт-код. Если вы используете фреймворк, то артефактом у вас будут вызовы каких-то конкретных функций/шаблонов/API этого фреймворка, а не скрытый за ними код. Через LLM вы обычно получаете код, т.е. артефакт принадлежит более низкому уровню абстракции. У вас в репозитории не хранятся промпты, которыми был код сгенерирован. Если не записано намерение, то совместная работа опускается минимум на один уровень абстракции ниже, а собственно намерение придется выковыривать из него. И вся сложность решения остается как есть, без инкапсуляции.

Вторая — воспроизводимость. Компилятор преобразует один и тот же вход в один и тот же выход. Обращение к фреймворку приведет к одному и тому же участку кода. Если, например, у вас написано json.dumps(obj), то это будет везде работать одинаково (если не быть ультрадушнилой). Нейронка же вам будет выдавать на один промпт разный результат каждый раз. Поэтому их и хранить бесполезно (так-то нейронки могут легко и всякие верхнеуровневые инструкции игнорировать). Без воспроизводимости придется либо переделывать одну и ту же работу по проверке качества и/или играть в рулетку при каждом изменении. А каждый проект с такой “абстракцией” становится “снежинкой”.

Третья — ответственность. У компилятора/языка/фреймворка есть разработчики, документация, какое-никакое сообщество и т.п. Если в них обнаружится какая-то проблема, то, скорее всего, она будет не только у вас, и у разработчиков будет мотивация это исправить. Еще у популярных инструментов есть какая-никакая репутация, и шансы, что они будут творить какую-то дичь, не очень высоки. У LLM ноль агентности с точки зрения ответственности, и в итоге артефакт с более низкого уровня абстракции становится вашей проблемой. А адекватному бизнесу нужна как раз предсказуемость.

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

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

P.S. Кстати очень забавно читать некоторые новости про ИИ/LLM, заменяя все это на “аутсорс”:)

Сабж.

Для “продвинутых пользователей” — в форме душной таблицы. Но даже она неполная.

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

Обычно под преждевременной оптимизацией имеют в виду переоптимизации в коде, который находится не на критическом пути, или микрооптимизации типа x = (x * 0xCCCCCCCD) >> 35, которые обычно вредны. И что, разумеется, нужно ориентироваться на бенчмарки.

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

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

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