🌧 Оптимизация Java-приложений для Arm64 в облаке

JVM в первую очередь процесс операционной системы. Но важно понимать, что требования к этому процессу на production отличатся от требований на workstation-е разработчика.

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

В новом переводе от команды Spring АйО разберем, какие существуют базовые настройки кучи, GC и CPU помогают синхронизировать JVM с лимитами контейнера и не переплачивать за простаивающие ресурсы.

Комментарий от Михаила Поливаха:

Все оптимизации в статье применимы не только к ARM-овым CPU, но и к x86. Это важно, потому что большая часть Ваших серверных workload-ов, даже если Вы об этом не знаете, они бегут на x86_64. Поэтому, статья для Вас тоже актуальна.

📚Полный текст по ссылке: https://habr.com/ru/companies/spring_aio/articles/1003602/

🔥 Тестирование API простыми словами + практика | Postman, Connekt

В новом видео разбираем тестирование API с нуля: что такое API, как работает HTTP, и переходим к практике в двух инструментах — Postman и Connekt.

В части про Postman: создаём GET и POST запросы, импортируем коллекции из Swagger, cURL и браузера, перехватываем трафик и настраиваем переменные окружения.

Дальше — то же самое в Connekt: импорт из Postman, работа с эндпоинтами Spring-приложения, все основные HTTP-методы, авторизация, работа с файлами, assertions и сложные сценарии с цепочками запросов.

😉 СМОТРЕТЬ НА YOUTUBE
😄 СМОТРЕТЬ В VK ВИДЕО
🥰 СМОТРЕТЬ НА RUTUBE

⏱ Часы Лампорта

Сегодня мы живём в мире распределённых систем: Apache Kafka, Apache Spark, Apache Cassandra — это уже не экзотика, а повседневная инфраструктура продакшена.

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

Как понять, что произошло раньше, а что позже, если глобального времени не существует?

Здесь в игру вступают логические часы Лампорта — простая, но концептуально мощная идея, лежащая в основе причинно-следственного порядка в распределённых системах.

📚 Подробнее тут: https://habr.com/ru/companies/spring_aio/articles/1005934/

👩‍💻 Cursor теперь доступен в IDE JetBrains

Cursor пришел в IDE JetBrains: IntelliJ IDEA, PyCharm, WebStorm и другие теперь подключают его через Agent Client Protocol (ACP). А это значит, что работать с агентом можно прямо в JetBrains-IDE.

Cursor ACP дает выбор модели под задачу: OpenAI, Anthropic, Google и модели Cursor. Под каждую модель у Cursor своя агентная обвязка, чтобы держать качество и скорость.

Как включить:

– установить Cursor ACP из ACP Registry
– авторизоваться существующей учеткой Cursor

Плагин является бесплатным для пользователей на платных тарифах Cursor.

🔗 Подробнее тут: https://habr.com/ru/companies/spring_aio/articles/1006764/

🔓 Copyright больше не защищает ваш код

Я тут поймал себя на мысли про ИИ-агентов и open source. Сразу уточню: речь не про проблему обучения ИИ на коде под лицензией.

Не знаю, как кодят другие, но мой текущий процесс выглядит примерно так:

• Сначала собираю спецификацию (конечно, с помощью ИИ);
• По спецификации делаю план реализации;
• План отдаю ИИ-агенту.

В плане есть:

• гейты перехода между этапами;
• тесты;
• definition of done.

Дальше агент просто проходит по плану. Конечно, я сильно упрощаю, но общий принцип понятен.

И вот здесь возникает интересный момент.

Спецификацию можно собрать практически из чего угодно.

Например, из проекта под «заразной» лицензией вроде GNU GPL.

Можно внимательно изучить проект и написать подробную спецификацию:

• какие есть модули;
• как они взаимодействуют;
• какие алгоритмы используются;
• какие интерфейсы между компонентами.

По сути — полностью описать архитектуру системы. Причём даже не обязательно делать это вручную: с такой задачей вполне справится любой вменяемый ИИ-агент.

Дальше по этой спецификации другой ИИ-агент составляет план реализации, и запускается разработка. Через несколько итераций получается новый проект:

• он работает;
• код другой;
• структура файлов может быть другой;
• даже язык программирования может быть другим.

Но по сути это та же система, просто переписанная по спецификации.

Фактически получается что-то вроде автоматизированной clean-room реализации.

И вот тут возникает вопрос:

Защищает ли open-source лицензия от такого сценария?

Кажется, что нет. Потому что copyright защищает:

• конкретный код;
• конкретную реализацию.

Но не защищает:

• идеи;
• алгоритмы;
• архитектуру системы.

ИИ просто делает переход от чужой архитектуры к новой реализации очень дешёвым.

Раньше clean-room реализация требовала команды инженеров. Теперь это можно провернуть с помощью одного человека и пары ИИ-агентов (умножить на X).

Поэтому у меня появилась мысль:

Возможно, если кто-то действительно хочет защитить open-source проект от подобного «переизобретения», одной классической лицензии уже недостаточно.

Потому что лицензии регулируют копирование кода, а не пересборку системы по её описанию.

Утекшие исходники

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

Возможно, ИИ просто подсветил старую юридическую проблему, которая раньше была менее заметна.

❓ Интересно, обсуждалось ли это уже где-нибудь.