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

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

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

Если уведомлений от GitHub слишком много, то можно:

1. Слать уведомления из рабочей организации — в рабочий ящик, а остальные — в личный с помощью роутинга.
2. Открыть настройки уведомлений и… настроить их!
3. Читать уведомления на самом GitHub, а не из почты-помойки.
4. Отслеживать статус своих PR и запрошенные ревью на странице с PR (туда же можно добавить фильтр по организации, если надо).
5. Использовать кнопку отписки об уведомлениях (шок!).
6. Настроить напоминалки для Slack на все действия, связанные с пулл-реквестами (либо мгновенные, либо по расписанию).
7. Наконец, настроить фильтры на почте.

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

Неплохая статья про оптимизации, которые используются в Bun (который альтернатива npm):

• минимизация количества системных вызовов и переключений контекста;
• асинхронный доступ к DNS;
• бинарный кэш;
• оптимизированная распаковка tar-архивов;
• параллельные массивы для хранения метаданных, подстроенные под кэш-линии;
• жесткие ссылки и copy-on-write для оптимизации копирования;
• пулы для задач с очередями без локов.

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

GitHub немного тупенький и не умеет нормально показывать, что изменилось в PR после ребейза и форс-пуша. Чтобы облегчить себе и ревьюеру жизнь, стоит делать два форс-пуша: один для ребейза на главную ветку, а второй для обновления коммитов в вашей ветке. При таком подходе в истории PR будут две записи про форс-пуш, у каждой будет кнопочка “Compare”, и, соответственно, можно будет посмотреть отдельно изменения по мухам (изменениями, связанными с главной веткой) и отдельно по котлетам (изменениями коммитов в ветке).

Внезапно, термин “лямбда-исчисление” появился из-за того, что издатель Чёрча не умел делать крышки над символами:

As the story goes, Church’s publisher did not know how to print a circumflex on top of an x, so instead he had the letter preceded by a symbol resembling a circumflex, namely the capital letter lambda (Λ), which was later replaced by the lowercase letter lambda (λ). Although Bourbaki’s notation (x ↦ x×x) prevailed, Church’s notation is still used in logic and computer science, and the very name of this new language is derived from Church’s notation: it is called lambda calculus.

Источник: Computation, Proof, Machine

Забавно, что даже в современное время не так-то уж и просто это сделать: например, Arial или Times New Roman будут показывать X̂x̂ некорректно. Посмотреть можно, например, тут. Вдвойне забавно, что на этом сайте нельзя расшарить пример текста с управляющими символами — код работает с ошибкой (а нормальный я заленился искать).

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

Докладчик на примерах итератора, AutoClosable, перегрузки операторов, литералов для коллекций, инстансов класса по умолчанию и прочих подобных фич демонстрирует проблемы с прямолинейным использованием интерфейсов по сравнению с отдельным классом. Уже сейчас это можно увидеть на примере Comparable<T> и Comparator<T>.

На 25 минуте появляется… моноид :D Потом еще свидетельства для тайп-классов (тот же Comparator<T> — свидетельство, что для T есть операция сравнения). По сути, плавно объясняется концепт тайп-классов из ФП (aka given/implicits в Scala) для мамонтов-джавистов. Под конец проходится еще по конвертациям (Short в Integer) и перегрузке операторов.

Видимо, фичи можно официально объявлять мейнстримом, если они даже в Java появляются.

В каждом утюге новости то про то, что если не используешь ИИ, то тебя уволят, что ИИ решит все проблемы, но при этом лишит всех работы (кроме CEO, конечно). Ну и если ты не используешь ИИ, то ты лох (no FOMO).

При этом только 5% ИИ-проектов приносят какую-то прибыль. А если посмотреть с точки зрения экономики всего этого безобразия, то все еще грустнее: да, цена старых моделей становится ниже, но они никому особо и не нужны, потому что требования растут; подписки на ИИ убыточны для всех компаний, но повысить цены тоже не могут — все убегут к конкурентам; что они будут делать в будущем — неясно. Большинство бизнесов с ИИ нежизнеспособны: дохрена компаний — это просто обертки к LLM, которые можно завтра скопировать; даже у ChatGPT конверсия около 2%; многие стартапы даже не имеют какой-то бизнес модели. Многие сравнивают ситуацию с пузырем доткомов, и что-то в этом есть: сейчас, как и тогда, разрыв между суммарной стоимостью акции и стоимостью активов превышает 400%.

Разумеется, какая-то польза от LLM есть (знаете, я и сам своего рода генератор текстов). И знакомиться с новыми инструментами нужно: оценить, чем они отличаются от старых, понять границы применения, эффективность и т.п. Но намеренно заставлять всех пользоваться микроскопом, что бы не только забивать гвозди, но и блины печь — это просто тупо. Хороший работник — не тот, который использует все самое новое, а кто знает какие инструменты когда использовать (и как). Если бизнес можно навайбкодить, то и цена у него невелика.

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

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

Современный CSS должен убить SPA с его джаваскиптами, провозглашает статья. Вау, круто, я тоже такого мнения, думаю я. Звучит очень интересно, молочные берега, кисельные реки, CSS может почти все! Просто добавь красивые переходы между страницами десятком строчек и у пользователя не будет ощущения, что он загружает новую страницу! Демки еще прикольные — прогресс же!

Пробую добавить на сайтик — не работает. Выясняется, что в Firefox поддержка не реализована. Пробуем в Chrome — все равно дергается при переходе на другую страницу. Может, дело в полосе прокрутки? В зависимости от ее наличия меню выравнивается по-разному. Лепим scrollbar-gutter — все равно все дергается. Отключаю полоску сверху — дергается, но поменьше.

Ладно, гулять так гулять — может, спекулятивную загрузку еще сделать, как в статье предлагалось? Добавляем в заголовок скрипт (фу, я же хотел меньше JS) и… ничего не поменялось. Ок, лезем в инструменты разработчика — “130 not triggered”. Спрашиваем GPT, получаем порцию газлайтинга, но в итоге после “глубокого анализа” получаем предложение в настройках хрома включить расширенную загрузку — ура, теперь инструменты разработчика светятся зелененьким, что страницы предзагружаются!

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

Хороший разбор про недавнюю историю с Bitnami. Кто не в курсе, они предоставляли довольно качественные VM-образы и докер-контейнеры для популярного ПО, и если у вас есть кубер, то с большой вероятностью, что-то от них используется (например, какой-нибудь helm-chart).

К ним пришел терминальный капитализм в лице Broadcom, который купил VMware, владеющую ими, в ноябре 2023. Broadcom — те самые ребята, которые пойдут на все ради 500% прибыли. И все, чего касается их рука, рано или поздно лишается бесплатного варианта. Эффект сравним с leftpad, только тут все осознанно — чтобы все пользователи платили большие бабки, потому что альтернатива (писать свое) еще дороже.

Джавистам стоит немного напрячься от этой новости, потому что Spring’ом сейчас владеет тот же Broadcom, и, судя по тому, как развиваются события, скоро он может перестать быть бесплатным. Да, можно форкнуть, но на поддержку и развитие что Bitnami, что Spring нужно будет много ресурсов.

Неплохой доклад про подход к внедрению изменений в компании.

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