Телеграм, кстати, тоже теперь позволяет верифицировать номера через них: https://core.telegram.org/gateway. Стоит цент.

Опенсорс голосовалка за фичи юзерами
https://github.com/getfider/fider

Правильное использование LLM:

https://www.bullshitremover.com/

https://news.ycombinator.com/item?id=41931938

Двойную gzip-бомбу на /wp-admin я, пожалуй, вставлю во все конфиги nginx, к которым имею доступ)

у меня есть слайд со скриншотом из 2016 года.
многие команды начинают ссыпаться уже на 4м пункте

Ну какие проблемы мы словили при массовом внедрении:
- Выяснилось, что современные react разработчики очень плохо умеют с этим работать, они привыкли готовить приложения определенным образом, по шаблону и у большинства не было понимания, что такое код работающий на сервере, какие есть нюансы, как его готовить, где водораздел клиентского кода и серверного. Многие пытались на нексте соорудить привычные react-redux-mobx-whatever приложения и получался дикий оверхед и по сложности кодовой базы и по дебагу этого хозяйства.
- Пытались некст горизонтально масштабировать и георезервировать - ловили кучу проблем с инвалидацией, неконсистентностью кэшей, сетевые запросы не всегда уходили куда надо.
- Приложения стали этакими сцепленными монолитами, просто раскидать статику по s3 и поставить перед ними nginx уже не хватало - нужно было значительно усложнять пайплайны.
- Были попытки сделать на этом всем подобие микрофронтовых оркестраторов, но тоже отказались из-за оверхеда. Ну и некст откровенно не для этого создавался.
- Намучались с server actions, они тогда только появились и не все понимали как их готовить (мало кто из команды видел PHP вживую 😀 и понимал как это - отправлять данные POST обновлением страницы)

Если резюмировать, то я просто понял границы nextjs и где его можно применять. И лучше не тащить в него какой-то лютый кастом и всякие модные стейт менеджеры, а просто юзать "по инструкции". Ну и просто упаковать в контейнер, а не раскидывать по CDN с кучей реверс проксей.
В совокупности с каким нибудь tailwind и например при отсутствии людей на бэке (команды нет например, а делать запросы к IDP или БД надо) очень даже хороший инструмент для шаблонных приложений.

Смотрел, выглядит хорошо: и feature exposure, и experiment exposure удобно сделаны, в growthbook сделали совместимое с этим «стандартом» апи, отлично работает год с лишним в проде и на фронте, и на беке. С перфом проблем нет: прокси внутри кластера поднимается легко (в стандарте этого не было, в реализациях есть), в клиент (сервис или бек, которые сплитует) скидывается конфиг, поэтому на один под достаточно 1 запроса в минуту

А больше там ничего и не надо, сервис, который примет колбеки и закинет в кх и можно ехать

Обучение разработчиков прошло не без проблем, но они бы были везде:
- главная абстракция тут — это фича флаг, он уже привязывается к экспу или другому роллауту, поэтому если выкатить на precentage rollout exposure не придет, всё понятно, но требует привыкания
- клиенты _должны_ реализовать кэширование конфига у себя и вынести колбеки в очередь, но это легко сделать 1 раз на язык и везде юзать либу
- интеграция помогает запускать больше экспов, НО нужны аналитики, чтобы: правильно посчитать MDE, определить неймспейсы и рассказать про математику продактам, разобраться с движками для подсчета и тд, без этого будет не data driven
- с exposure нужно осторожно: легко «оптимизировать» и зарезолвить все нужные фичи, но это сломает аналитику

Все проблемы минорные, мне апи и идея очень нравится, для контекста: я завозил growthbook в организацию на ~100 инженеров, делал сервис для принятия колбеков, джавый стартер для интеграции и помогал другим разобраться

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