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

1. с флагом --rerun-tasks
2. с --no-configuration-cache
3. с --no-build-cache
4. после clean
5. с чистой домашней папкой Gradle: --gradle-user-home ./gradle_home
6. после убийства всех демонов Gradle (по идее то же самое что и выше, но стоит попробовать)
7. после рестарта IDE, если вызываете билд из нее.
8. после очистки папки с исходниками от всего лишнего: git clean -ffdx.

Если вышеперечисленное не помогло, то скорее всего проблема где-то в билд-логике и/или окружении.

У Postgres отличные доки. Например, достаточно одной странички, чтобы узнать большую часть необходимой информации, которую нужно знать про виды локов в БД.

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

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

Однако после непосредственно программирования вскрывается, что и условие, мягко говоря, не очень точное/полное, да и описания решений умалчивают о куче нюансов и/или имеют неясности. Я очень долго вникал в решение от Дейкстры, и еще дольше — в статью Чанди-Мисры с универсальным решением. И не могу сказать, что я на 100% понял, как они должны работать, и как стыкуются с изначальными неясностями в условии. Я более чем уверен, что налажал с их реализацией. По Чанди-Мисре смотрел готовый код и там все в итоге сводилось к переизобретению упорядоченных ресурсов. И в итоге лучшим оказалось одно из простейших решений.

А еще примитивы java добавили веселья: семафор, которому можно бесконечно увеличивать количество разрешений — ну, такое.

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

Код можно посмотреть тут.

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

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

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

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

Интересно, как отреагируют дистрибутивы Linux, во многих из которых ФФ — браузер по умолчанию.

SWE-bench — это бенчмарк на основе ~2300 реальных тикетов и связанных пулл-реквестов из 12 GitHub репозиториев на питоне. Его часто используют для того, чтобы заявить, что скоро нейронки заменят прогеров: например, недавний Claude 3.7 показал в нем аж 70% (в то время как у текущих рекордсменов — 49%). Бенчмарк изначально задумывался как способ проверки решения “реальных” проблем в реальных проектах.

Вообще, вопросы к репрезентативности должны возникнуть уже на стадии более подробного описания/аннотации (только питон, 12 реп и т.д.), но для своего времени (полтора года назад всего) бенчмарк был хорош — лучшая модель в нем набирала меньше 2%. А вот год спустя появилась статья с качественным анализом бенчмарка.

Результаты получились довольно яркие:

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

Соответственно, если улучшить тесты/условия, то и проценты в бенчмарках будут на порядок ниже. Вот такие маркетинговые пироги :)

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

Захотелось потешить свое эго и вывести красиво список своих PR.

Попробовал несколько готовых страничек, но они все были унылы в той или иной степени (я конечно все понимаю, но смотреть сгенерированный сториз — ну, такое).

В итоге сделал свою. Причем включил максимальный уровень лени и сделал это чистым promt-инженерингом: все написал ChatGPT за 7 коротких промптов, я ни строчки в коде не тронул.

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

В продолжение поста про кроссплатформенность bash: даже если вы проверили скрипт каким-нибудь shellcheck на совместимость с POSIX, это не значит, что он будет работать на всех POSIX-совместимых платформах. Это даже не значит, что работать на всех современных POSIX-совместимых платформах, потому что есть какая-нибудь z/OS для мейнфреймов, которая вышла 1,5 года назад, и которую кто-то даже использует.

Очевидно, что у POSIX есть несколько версий стандартов, причем последняя — аж от 2024 года! Изменения не очень впечатляющие — всякие API для C11, флаги к командам, которые и так уже были, удаление устаревших API и т.п. Т.е. это скорее фиксация текущих распространенных практик, чем изобретение чего-то принципиально нового.