Они же cohesion и coupling, тяжело подобрать перевод получше. Первый термин — про то, насколько близки элементы внутри модуля (например, все связанное с пользователем в одном модуле, а все с его заказами — в другом), второй — про количество связей между модулями (негоже сервису заказов лезь напрямик в БД пользователей). Считается, что в идеале должен быть сильный фокус и низкая связанность, однако только ситхи возводят все в абсолют и надо знать меру. Подробнее можно почитать в этой годной статье.

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

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

Без виртуализации, просто как приложение. После Linux в браузере и Linux в PDF уже не так удивительно (да и вообще каждый утюг тюринг-полный в наши дни), но статья все равно занятная. Однако практическая польза стремиться к нулю.

Годная статья про основные принципы DevEx (продуктивность разработчиков). Если кратко, то нужно:

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

В качестве проблем выделены:

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

Один и тот же проект (curl), одна и та же задача (найти уязвимости).

Подход номер 1 — “сделай все за меня”. Результат — говно-отчет об несуществующей уязвимости, пустая трата времени для всех, репортера забанили (и поделом).

Подход номер 2 — использовать ИИ как один из инструментов и не забывать про собственные мозги. Результат — найдено несколько реальных проблем, автор проекта в восторге, доклад на конфе, инструменты стали лучше (потому что касается не только curl).

Имхо, отличная иллюстрация как надо и не надо делать.

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

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

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

Если уведомлений от 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 появляются.