Context Collection Competition от Jetbrains

Стартует соревнование по обработке контекста кода.
Скорее это разработка на заказ, но с бонусом и возможностью порекламиться.

Мне кажется, что финальное решение пойдет в саму IDEA или плагины, чтобы собирать и обрабатывать контекст для AI Assistant и Junie, чтобы они работы быстрее, без надобности делать ls -la / в консоли.

Даты, забрал с лендоса:

June 2, 2025: competition opens and practice phase begins
June 9, 2025: public phase begins
July 25, 2025: public phase ends, private phase begins
July 25, 2025: solution paper submission opens
August 18, 2025: private phase ends
August 18, 2025: final results announced
August 26, 2025: solution paper submission closes
November 2025: solutions presented at the workshop

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

По ссылка можно почитать больше инфы.

Лендос: https://lp.jetbrains.com/research/context-collection-competition/
Eval.AI: https://eval.ai/web/challenges/challenge-page/2516/overview
Github: https://github.com/JetBrains-Research/ase2025-starter-kit

——

@handle_topic

PHP 30 лет

```
В этот день написали меня на свет
В этот день с иголочки сеньор одет
В этот день теплом ваших серверов я согрет
Мне сегодня тридцать лет
В этот день скажу миру: «Hello world»
В этот день я в True Async возьму билет
В этот день и exit() не во вред
Мне сегодня тридцать лет
```

Приходите на стрим от CutCode по поводу дня рождения PHP с блек джеком и мерчом

🎉 30 лет PHP! Присоединяйтесь к праздничному стриму!

Завтра, 8 июня в день рождения PHP в 18:00 (мск) вместе с Сергеем Пантелеевым:
🔹 Пообщаемся, обсудим итоги опроса (успейте заполнить форму → https://forms.gle/X2uw61xAxhX88uiQ6)
🔹 И... разыграем слонов! 🐘

Не пропустите! 🚀 - https://youtube.com/live/85xnTYzVtgw
#PHP30

Начинается!

Собираем красивые тексты ошибок

Я люблю делать тексты ошибок понятными, читаемыми, информативными и стилистически красивыми.

База:
- заключать все подстаноуки в кавычки
- использовать двойные кавычки, вместо одинарных
- дочитать до конца и увидеть последний пункт

В далеком 2020 году я создал PR в Doctrine, но его морозили, и я не интересовался пинанием его дальше. 

С того момента Doctrine изменилась сильно, но узнать плохое написание текстов с ошибками можно по первому байту. Сейчас всё расскажу.

Представим строчку:

"Invalid literal '" . $literal . "'"

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

Например, это могло бы выглядеть так:

"Invalid literal '$literal'"

Чуть более явный вид будет такой:

"Invalid literal '{$literal}'"

Более явный – потому что фигурными скобками я подчеркиваю намерение сделать интерполяцию, а не написать $literal просто как текст, исключая возможность перепутать свои намерения.

Следующий уровень мастерства (ирония) – вовсе не писать кавычки в подставляемые значения:

'Invalid parameter: token ' . $key . ' is not defined in the query.'

В итоге, когда получите ошибку при $key = " "

Invalid parameter: token  is not defined in the query.

И HTML склеит 2 пробела в 1, текст будет очень полезным и вспомогательным. Найти такие ошибки в исходниках бывает очень сложно, хоть здесь всего лишь 1 подстаноука.

Даже когда вы получите ошибку при $key = "function"

Invalid parameter: token function is not defined in the query.

То сможете запомнить, что подстановки в данной библиотеке происходят без кавычек вовсе.

Так вот, когда вы получите первую ошибку где-нибудь на веб странице и она будет выглядеть так:

Invalid literal '5'

После того и будете думать, что '5' – это значение подстановки.
То есть, в переменной типа string лежат 3 символа: кавычка, число, кавычка.
Искать такое значения у себя по коду или алгоритмам, которые могли бы выдать такое значение сложно. Тем более, если они такого не делают.

Если открыть исходники и увидеть способ формирования строки ошибки:

"Invalid literal '" . $literal . "'"

Можно предположить, что $literal = "5" или $literal = 5. Уже лучше, но порой бывает нужным еще и тип переменной вывести.

Я уже много лет предпочитаю другой способ записи ошибок/интерполяции строк – через sprintf:

sprintf('Invalid literal "%s".', $literal)

Этот вариант позволяет мне делать всё что захочу с текстом ошибки: кавычки, переносы строк, вложенные интерполяции, удобный поиск таких строк.
Я не теряю контекст текста ошибки, когда читаю или пишу его. Я могу писать $ в тексте и не думать про интерполяцию.

Когда текст ошибки простой – я позволяю себе делать простую конкатенацию

'An error occurred: ' . $error

Почему я считаю такое позволительным:
- не нужна интерполяция в конце, потому что дальше подстановки ничего нет – ни кавычек, ни точки, ни продолжения текста
- текст ошибки явно отделяет себя от подставляемого значения через символ двоеточия
- благодаря такому разделению можно не писать кавычки

Хоть текст 'An error occurred: %s' был бы полезнее при учетом интернационализации (i18n) приложения, без i18n такое использование вполне элегантное.

Кстати, Intellij IDEA позволяет превратить строку с конкатенацией в строку с sprintf за пару кликов при помощи интентов:
- Option + Enter – нажать комбинацию клавиш на строке
- "spr" – для удобной фильтрации выдаваемых интентов
- Convert string interpolation to a sprintf call – название нужного нам интента

Потом расскажу про интерполяцию в Kotlin, куда без этого.

Как вы относитесь к подстановкам через sprintf vs string interpolation?

---

PR: https://github.com/doctrine/orm/pull/8212
Doctrine/QueryException: https://github.com/doctrine/orm/blob/3.4.x/src/Query/QueryException.php#L80

---

@handle_topic

XML Clark Notation

Не так давно пришлось столкнуться с парсингом XML на JS.
С виду всё просто:
- Берем парсер из браузера, либо ставим свой
- Создаем парсер: new DOMParser()
- Запускаем parseFromString(string)

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

...
<m:r>
 <w:rPr>
  <w:Fonts w:ascii="Cambria Math" w:hAnsi="Cambria Math" />
  <w:w w:val="105" />
 </w:rPr>
 <m:t {http://www.w3.org/XML/1998/namespace}space="preserve">,
 </m:t>
</m:r>
...

Я не сразу увидел, но потом как увидел!

<m:t {http://www.w3.org/XML/1998/namespace}space="preserve">

Сначала я подумал, что это какой-то невалидный XML и с парсером всё ОК. Однако, попробовал другие документы и обнаружил, что баг всё-таки не в XML, а в парсере.

Такая запись называется Clark Notation, она представляет из себя "inline" неймспейма документа прямо в место использования этого атрибута/тега.
Вместо объявления xmlns, namespace пишется прямо в фигурных скобках: {http://example.com}element.

Если сделать обратное преобразование, то результат будет примерно такой:

<m:t xmlns:ns="http://www.w3.org/XML/1998/namespace" ns:space="preserve">

Т.е.:
- Мы вытащили содержимое в фигурных скобках в отдельное указание неймспейса
- xmlns=NS_NAME="NS_VALUE"
- И заменили эти символы на использование этого неймспейса
- NS_NAME:space

Такое преобразование можно делать в обе стороны и даже иметь несколько инлайнов в одном теге, либо даже неймспейс тега заинлайнить:

Например, было:

<cars:part xmlns:cars="http://www.cars.com/xml"/>

Стало:

<{http://www.cars.com/xml}part/>

Выглядит короче (иногда), но JS парсер с таким не справился!

А как же PHP?

PHP Warning:  simplexml_load_string(): Entity: line 1: parser error : Couldn't find end of Start Tag tag line 1 in php shell code on line 1

Еще пыха сходит с ума и выводит эту ошибку раз 10!

А вот что получилось в Kotlin!

Element type "tag" must be followed by either attribute specifications, ">" or "/>".

В общем, стандартные средства не понимают этого Кларка.
Я сделал небольшую функцию на регулярке и циклах с заменой подстрок {...}attr на xmlns:nsN="..." nsN: и теперь всё работает как надо.

Кто-то сталкивался с этим Кларком? Как решали подобное?

——

Небольшая статья от того самого Кларка: http://www.jclark.com/xml/xmlns.htm
Вроде даже есть библиотека на PHP: https://sabre.io/xml/clark-notation/

——

@handle_topic

Так и живем 🤷‍♂️

Работа с кодом в презентациях

Кто хоть раз создавал презентации в которых нужно показать код, тот может вспомнить, насколько плохо это сделано в редакторах презентаций.

Не так давно нашел инструмент для помощи создания контента для презентаций: SlidesCodeHighlighter

Что он позволяет делать:
- Выбрать язык для подсветки
- “Авто” язык тоже хорошо работает
- Есть возможность выбрать тему, как светлую, так и темную
- Шрифты, размеры шрифта
- Мультикурсоры
- Возможность выделить текст и повлиять на текст “рендера”: сделать его жирным, сделать текст ярким, а все остальное бледным и тп

Как это работает:
- Заходишь на сайт инструмента
- Вставляешь код, который нужно подсветить
- Текст генерируется с обёртками вокруг слов, который подкрашиваются через <span style=“color: …”>
- При копировании копируются все стили текста
- При вставка ваш редактор парсит эти стили и текст, создает своё представление и вы получаете раскрашенный код

Работает с Keynote и Arc на Mac.

——

Ссылка: https://romannurik.github.io/SlidesCodeHighlighter

——

@handle_topic

Новости из мира #PHP

В последнее время я много уделяю времени контрибьютингу в PHP Core. Решил поделиться новостями за последнее время. Довольно много всего вылилось.

Single Expression Functions (SEF) перевел на стадию голосования.

Честно говоря, думаю его никто не лайкнет. Вопросов было мало, хоть и изменение в пару строк. Предыдущая попытка была от Larry Garfield несколько лет назад, но не прошло из-за нерелевантных вопросов и утверждений.
В общем, через 2 недели узнаем итоги.

Обсуждение: https://externals.io/message/127423
RFC: https://wiki.php.net/rfc/single-expression-functions
GitHub: https://github.com/php/php-src/pull/17677

—

CHIPS RFC
Столкнулся на работе с отсутствием поддержки CHIPS в PHP при использовании setcookie, который используется в Yii2.
Пришлось сделать PR. Спросил нужно ли готовить RFC, а мне сказали, что был уже предыдущий заход от Niels Dossche.
Списался с ним, пообщались, сделали совместный RFC. Нильс выражает опасение: даже ради такой плёвой штуки подстраховался и накинул в RFC объяснений. Видимо тоже отвергали сотню раз уже.

Мой PR: https://github.com/php/php-src/pull/19054
Обсуждение: https://externals.io/message/128047
RFC: https://wiki.php.net/rfc/chips
GitHub: https://github.com/php/php-src/pull/12652

—

Async Engine API вышел на обсуждение.

Я думаю, это какая-то база для асинк фреймворков, чтобы они смогли адаптировать свои реализации под стандарты.

Комментарий от Edmond Dantes, инициатора этого RFC: Это базовое апи для расширений, которые будут предоставлять async возможности.

Можно поиграться с докером:

# Build the image
docker build -t true-async-php .

# Run interactively
docker run -it true-async-php bash

Dockerfile: https://github.com/true-async/php-async/blob/34eaee6a28d9c27a2f579e7cece28877c5e7666d/Dockerfile
Обсуждение: https://externals.io/message/128053
RFC: https://wiki.php.net/rfc/true_async_engine_api
Оригинальный RFC: https://wiki.php.net/rfc/true_async
GitHub: https://github.com/php/php-src/compare/master...true-async:php-src:true-async-api-stable

—

Short Constructor
Случайно всплыл Records RFC и я вспомнил о крутой фиче в Kotlin – короткий конструктор
Долго не думая, запилил бетку, практикуясь писать сишный код.
Закинул на обсуждение всем с возможным развитием в создание RFC.
Поговаривают, что изменение синтаксиса не сильно любят в Core.

Обсуждение: https://externals.io/message/128060
Обсуждение Records: https://externals.io/message/125975
GitHub: https://github.com/php/php-src/pull/19133

——

@handle_topic

Junie on Github!

Jetbrains выкатили возможность использовать джуна на гитхабе:
- Создаете Issue
- Назначаете исполнителем Junie
- Идёте заваривать кофе, ведь скоро останетесь без работы и нужно привыкать к беззаботной жизни
- Проверяете решение

Можно еще и тегать в ревью, чтобы он пришел ревьювить сам.

Если вы поддерживаете Open Source, то прямо сейчас можете подать заявку на получение бесплатного 6 месячного пробного периода!

Я подался, надеюсь получится двигать свои проекты быстрее и не проехать остановку!

Лендос и форма: https://www.jetbrains.com/junie-github/

—

@handle_topic

Python Console Plugin

Увидел сегодня такой плагин для питона в IDEA.
Скорее всего он идет от базового плагина для питона, но всё же.

Выглядит прикольно, в питоне консоль по сути является REPL (Read, Eval, Print, Loop).
Помню проект PsySH (псих), где можно писать практически как в IDE.

Так вот, может поделать таких плагинчиков?)

В PHP есть Interactive shell: php -a, может сделать аналог Python Console?

Кстати, в Python есть Jupyter Notebook. А что в Kotlin?
Kotlin Notebook!

В Kotlin нет Interactive shell из коробки, но есть решения отдельно.

——

@handle_topic

File System Info

Время от времени сталкиваюсь с нужной посмотреть размер конкретной директории и узнать её вес и количество файлов внутри.

Часто бывает такое, что есть какая-то директория, а в ней под сотню файлов, которыми никто давно уже не пользуется.

Для своего же удобства я предпочитаю держать файлы в тонусе:
- Не создавать под каждый "тип" файла отдельную папку
- Не класть в одну папку 20+ файлов

Помимо этого, иногда можно не заметить файлик, размером с весь проект: то количество строк больше пары тысяч, то вес файла больше 10мб.

В общем, превратил ручной труд в механический и сделал новый плагин для Intellij IDEA.

Плагин уже доступен в маркетплейсе, становится в любую IDE от 23 года.
Фидбек и пожеланию принимаются. Можно писать в коменты или в отдельном чате.

——

Маркетплейс: https://plugins.jetbrains.com/plugin/28300-filesystem-info
Исходники: https://github.com/j-plugins/fs-info-plugin
Чат для обсуждения: https://news.1rj.ru/str/jb_plugins/100

——

@handle_topic

Git Churn

В добавку к плагину File System Info @samdark предложил идею сделать подсчет и подсветку файлов, которые часто меняются.

Алгоритм следующий:
- git log с определенного времени до текущего
- Группировка и подсчет количества файлов

Теперь у нас есть карта "путь до файла" <-> "сколько раз был комит с файлом".

Так как директории в git не хранятся, то дополнительно требуется собрать список директорий и высчитать максимальное количество.
В зависимости от количества изменений нужно привести строчку с файлов в Project View к красному оттенку. Для этого можно высчитать формулу градиента и наложить такой цвет поверх элемента в Project View.

Что дает знание о количестве изменений файла:
- Кажется, что файл выполняет несколько функций и его стоит разбить на несколько
- Частые изменения файлов – потенциальное место конфликтов git merge
- Есть файлы, которые будут меняться часто и это нормально: конфиги, переменные, id и другое.

В остальных случаях точно стоит посмотреть на файл еще раз.

Плагин уже доступен в маркетплейсе

——

Маркетплейс: https://plugins.jetbrains.com/plugin/28319-git-churn
Исходники: https://github.com/j-plugins/git-churn-plugin
Чат с обсуждением: https://news.1rj.ru/str/jb_plugins/102

——

@handle_topic