Зарелизил таки новый плагин. Пока без лишнего шума. Но если у кого есть локализации в Laravel приложении, вполне могут посмотреть и некий фидбек оставить(буду благодарен).

https://plugins.jetbrains.com/plugin/24979-locale-sphere

Пока весь UI - это toolwindow справа на экране. Над плагином идет активная работа, как по фреймворкам(симфони на подходе), так и по фичам. Ссылка на багтрекер есть внизу окошечка.

В Java Swing есть много разных способов размещать компоненты внутри окошек. В давние стародавние времена я выбрал некий GroupLayout, который давал максимальный контроль. Потом я узнал, что его не рекомендуется использовать вручную и он вообще для этих редакторов, где мышкой интерфейс набрасывают, ну да ладно. До сих пор использую его, но там, чтобы указать как именно себя должен вести компонент, надо указать в правильном порядке комбинацию из трех параметров.

Логика какая-то наверняка в этом всем есть, но я никогда ее не осознаю и я никак не могу понять по этим параметрам как компонент будет отображаться: растянутым на всю ширину(высоту), средненько или будет занимать минимальную ширину(высоту). Поэтому давно еще создал методы-расширения, чтобы было более понятно. addComponentShrink - этот будет ужат до минимума. addComponentNotResize - этот будет нормально отображаться, но не будет растягиваться. Теперь решил подчистить весь код, чтобы не осталось ни одного вызова с этими тремя параметрами.

Вывод 1: далеко не всегда понятно, что код, который вот щас по гайдам из интернета сделан, будет непонятен при прочтении в будущем. Надо постоянно следить и скрывать такую непонятную логику в методах с нормальным названием. На картинке видна разница.

Вывод 2: методы-расширения весьма полезны в таких вот Fluent-вызовах методов, в которых return this. Поэтому я все больше и больше начинаю уважать ларавелевский ::macro(), который позволяет делать тоже самое в PHP, в котором нет поддержки методов-расширений.

Давно не запускал полный набор тестов в плагине на локальном компе. На Continuous Integration сервере запускаются после каждого git push, поэтому не парился. Но недавно запустив, осознал, что уже больше недели там есть тест, который падает. А на CI работает!

Причина банальная: когда на компьютере часовой пояс UTC, то тест нормально работает, а когда отличается - падает.

Вообще, такой ситуации быть не должно, и CI должен ловить такое, но что сделать для этого? Банально поставить ему другой часовой пояс? Крупные компании решают эту проблему как либо?

«Своя игра» по PHP на канале CutCode

Вы можете задать сейчас вопросы участникам викторины.

Самые интересные вопросы будут разобраны на игре, а их авторы получат возможность поучаствовать в следующей игре и получить мерч!

? 13 марта в 19:00 (мск)

? Александр Макаров
? Кирилл Несмеянов
? Адель Файзрахманов

? https://www.youtube.com/watch?v=WNIAO0kEk7U

Код Laravel Idea потихоньку приходит к канонам. К слоям. Я начал разделять его на отдельные проекты.

• Проект с общими хелперами, которые пригодятся другому плагину(сюда уедут процентов 10 кода).
• Проект с всей логикой Laravel Idea(тут будет 85% кода).
• Проект для связки Laravel Idea с PhpStorm.
• Проект для связки Laravel idea с Qodana.

Это все равно когда-нибудь произошло бы. Но теперь понадобилось для двух целей - специальной версии плагина для Qodana(CI тулзы от JetBrains) и нового плагина, который уже давно хотел начать, но вот сейчас только руки дошли.

Когда начинал писать плагин, думал что проект совсем иной и общего с веб-проектами с их слоями Application layer и другими нет. Тут очень все завязано на внутреннюю структуру IDE. Но чем дальше в лес, тем больше приходит понимание, что структура там тоже важна. И вырисовывались слои. А новые требования быстро помогли осознать, что пора их отделить уже физически.

Когда-то давно одним из основных продуктов JetBrains был Resharper. Умный плагин для C# разработки в Visual Studio от Microsoft. Долгое время спустя, убедившись, что они умеют делать собственные успешные IDE для кучи ЯП, они решили сделать Rider - среду программирования для C# (или всех .NET языков, тут не знаю). Но была проблема: тот умный решарпер, который понимал C# и на основе которого планировалось делать Rider, был написан на C#.

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

Архитектура Rider вынужденно повторила архитектуру современных SPA веб-приложений. И вроде бы получился некий уродец с кучей проблем. Тут и перформанс, и плагин нормальный написать - тоже надо и фронтэнд часть и бэкэнд. Но кто-то в JB решил, что это не баг, а фича!

И появился Fleet - "Next-generation IDE by JetBrains". Архитектура точно такая же - интерфейс это фронтэнд, а вся умнота(там это называется Smart mode) - бекэнд. А фича в том, что бэк можно разместить как на компе юзера(и тогда получим более-менее обычную JetBrains IDE), а можно на облачном сервере от JetBrains, Space! И это решит одну из главных жалоб юзеров - потребление кучи ресурсов(памяти и проца).

Я сегодня таки поставил и пощупал. Котлин оно понимает весьма неплохо. Интерфейс модный-молодежный. Как у VSCode. Настройки хранятся в json-файле. Как у VSCode. Да и smart mode напоминает language server протоколы, которые тоже популярны в вскоде. Но это JetBrains! Они умеют делать не только хорошо, а лучше всех. Надо еще подождать и посмотреть. Настроек очень мало. Плагинов пока никаких нет и апишки к ним не опубликованы.

Когда внезапно осознаешь, что твое приложение - многопоточное.

Прилетает в sentry такой эксепшен:

```

java.lang.ArrayIndexOutOfBoundsException: Index 1 out of bounds for length 0
at java.util.ArrayList.add(ArrayList.java:455)
at java.util.ArrayList.add(ArrayList.java:467)
at com.laravel_idea.plugin.translation.fetching.b.b.a(b.java:24)
```

Я просто вызываю add() в стандартнейшем классе для списков и получаю странную ошибку. Но крайне редкую. Для тысяч юзеров всего 2 за неделю. В многопотоковом программинге я ноль, но это оно самое. Два потока одновременно пишут в один список и получают ошибку. Вчера еще более странную ошибку находил, с той же самой причиной.

```

java.lang.ClassCastException: class java.util.HashMap$Node cannot be cast to class java.util.HashMap$TreeNode (java.util.HashMap$Node and java.util.HashMap$TreeNode are in module java.base of loader 'bootstrap')
at java.util.HashMap$TreeNode.moveRootToFront(HashMap.java:1986)
at java.util.HashMap$TreeNode.treeify(HashMap.java:2102)
at java.util.HashMap.treeifyBin(HashMap.java:770)
at java.util.HashMap.putVal(HashMap.java:642)
at java.util.HashMap.put(HashMap.java:610)
at com.laravel_idea.plugin.translation.fetching.b.b.a(b.java:16)
```

Если данные приватные и пишутся под строгим контролем одного класса, чинить это несложно. Простые конструкции synchronized и все должно быть ок. Также, есть специальные thread-safe структуры данных(ConcurrentHashmap, ConcurrentList). Но внутри у них либо тот же syncronized, либо еще хуже, так что для меня проще так.

```

synchronized(this) {
vendorData.add(data)
}
```