Григорий Мясоедов @grisha9
Java Developer, Open Source Contributor
Information
- Rating
- 618-th
- Location
- Рязань, Рязанская обл., Россия
- Date of birth
- Registered
- Activity
Specialization
Specialist
Lead
Java
SQL
Database
Android development
Java Developer, Open Source Contributor
Помимо "локальности" данных, новые inline/primitive типы позволяют аллоцировать данные "на регистрах процессорах", не делая дополнительных обращений к опереативной памяти и экономить такты процессора. В целом и сейчас такие кейсы могут упрощаться на этапе escape анализа. За то "скидывать" новые типы данные в ОП или нет, отвечает JVM
Это понятно. Но проблема как была так и остается - с использованием блокирующего кода внутри корутин - неважно IO или что то другое. И хорошо если IDE умеет распознавать такие случаи и подсказывать. А так это потенциально опасное место чтобы выстрелить себе в ногу. Именно этот минус я и имел ввиду.
По второму пункту вы сами ответили на свой вопрос - какой смысл использовать корутины, если есть возможность использовать JDK21 и выше.
Я бы к минусам корутин еще отнес - чтобы их эффективно использовать все IO вызовы внутри также должны уметь поддерживать корутины(быть не блокирующими), иначе при попытке вызова обычного блокирующего java метода внутри suspend функции это ни к чему хорошему не приведет. И об этом надо помнить постоянно(в отличии от Loom), а попытки решить эту проблему "разукрашивают" код еще сильнее. Похожий тред есть на stackoverflow.
Такое мог ляпнуть только необразованный человек, который либо не учился в школе или учился плохо. Получается что вторая мировая война сказалась на демографии Япония хуже чем на СССР? Потери Японии 2.5 млн, против 26.5 у СССР если что. Все это легко проверяется в интернете. Более того у Японии нет почти никакого провала по демографии в этот период в отличии от СССР. На начало войны 1941г - 72.7млн на 1945 72.4млн по данным с вики.
Если говорить про "совок", то надо сравнивать данные первой переписи 1926 г и последней в СССР 1991, а не начало и конец века. Так если что, в первую мировую войну потери России были одними из самых больших (тоже наверное "совок" виноват). И с этим "наследием" уже пришлось жить дальше СССР. Если говорить только про Россию/РСФСР то на 1926г было 100млн человек, на 1991г - 148млн. И отрицательное сальдо 41г-45г -23млн, вместо 0.3млн у Японии. Итого на 1926г Русских было в 1.6 раз больше, на 91г в 1.2 раза больше. Где тут три раза? я специально брал данные только по РСФСР, а не по СССР в целом. А если убрать провал по демографии России вызванный второй мировой, то получается что разница +- осталась такой же. И по данным из вики что я приводил, видно что например в тех же 80ых, рост численности был выше чем в Японии.
О как! оказывается все дело в законе. Удобная позиция, найти какой-то факт и полагать что дело только в нем и озвучивать факт только на половину. Что его отменили только в лихие 90-ые. А то что его ввели в ноябре 1941 года, то да, эта дата ни о чем не говорит.
А население росло потому что оно было уверено в завтрашнем дне. А заводы и вся инфраструктура которая была построена в СССР этому способствовала. И росло население с середины 20-ых годов(можете посмотреть в википедии), не смотря на первые самые тяжелые пятилетки и репресии второй половины 30х.
Здравствуйте. На сколько мне известно, по моим источникам, внутренний разбор по моей ситуации уже был. Что там у вас было решено по итогу если честно мне не очень интересно ни тогда (т.к. на тот момент я уже определился с новым местом работы), ни тем более сейчас, полтора года спустя. Но статьи с похожим содержанием нет нет, да периодически появляются, это о чем то, да говорит. Вообщем если вам интересно, мои ФИО есть в профиле, по ним со 100% вероятностью вы сможете найти данные обо мне внутри компании. И как я уже говорил в Тинькофф трудоустраиваться больше не собираюсь, поэтому полтора года спустя мне не очень интересна вся эта история. Но вы можете попытаться это исправить, для будующих потенциальных сотрудников.
Совершенно верно. Как я понял это мало кого интересовало - мой прошлый опыт в этой компании. Сначало надо было пройти сито обязательных секций, может быть далее при общении на конкретный проект, мой опыт бы и учли, но я до этого не дошел, т.к. после двух первых секций получил оценку мидл, и никакого далее разговора о пизиции senior речи быть не могло)
Кстати если в других компаниях что я указал, в процессе собеса, чувсвуешь что имешь разговор с квалифицированным инженерорм, то тут явно было ощущение что тебя гонят по опроснику и сверяют с эталоном. и есть только одно правльное решение и никак иначе.
upd: как сказали мои знакомые что там работают - мне просто не повезло с интервьюерами
В ali была классическая задача на поиск в ширину - найти кратчайший путь. В huawei проектировали структуру данных, для нахождения строк, по начальной подстроке. на знание trie - деревьев.
Напишу про свой опыт работы в Тинькофф). Я бекэнд java девелопер с 2011 года, проработал 6 лет в Тинькофф с 2015-2020г на позиции senior developer. Далее было немного Яндекса и JetBrains. В 2022г когда пришлось искать новую работу, по известным событиям, я собесился в компании Huawei/Aliexpress/РтЛабс/Тинькофф. Везде были сложные задания - включая алгоритмы на графах. И почти все собеседования, я прошел и более того мне дали именно те условия что я просил, кроме… правильно) Тинькова. Там я вообще не прошел собес, меня оценили на мидла по всем секциям и ответили отказом. Меня если честно это вообще не задело, т.к. собесился туда больше на всякий случай, да и в целом уже заранее знал куда пойду работать дальше.
А теперь немного подробностей, чтобы показать всю нелепость ситуации. На секции с техническим дизайном, проектировали систему по загрузке изображений. Я там немного похоливарил с интервьюером на тему, что лучше для той задачи - kafka или rabbit. Справедливости ради замечу, что задачу можно было решить на любом брокере. Как итог в обратной связи мне написали, что я не разбираюсь ни в том ни в другом. Для справки скажу, что еще в свой первый заход в тинькофф, я реализовывал отложенную отправку сообщений на rabbit и считаю что знаю его не плохо и в свое время прочитал если не всю, то большинство документации по нему на оф.сайте. Далее когда в компании появился кластер kafka, мы мигрировали часть функционала туда, и все новые фичи, где нужна была асинхронная отправка сообщений, реализовывали через kafka. Так что, я мягко говоря имел практический опыт сравнения двух брокеров и участвовал в разборе определенных “граблей” kafka вместе с командой, что отвечает за ее поддержку в компании. И имел хорошую репутацию внутри той компанды, в которй там работал с период 2015-2022г.
Благо у меня остались знакомые там, и рассказав им ситуацию, выяснилось следующее, что человек который меня собеседовал, был вообще аналитик… и в жизни не писал код в промышленном масштабе. что люди туда приходят просто с бумажкой, где сверяют твои ответы с тем что должно быть. И в ответах у него была только - kafka. По другой секции, где меня тоже оценили на мидла, интервьюер был в процессе увольнения, и ему просто было по сути все равно, что ставить в результате, скорее всего он так развлекался.
По итогу для себя я однозначно сделал вывод, что если есть такая компания в которой я больше ни при каких обстоятельствах работать не буду, как бы не сложилась жизнь - это однозначно Тинькофф.
продублирую ссылкой. т.к. "промазал" с ответом, а редактировать уже поздно. https://habr.com/ru/articles/759984/comments/#comment_25953974
Ковырял исходники idea) мне это также надо было для написания своего плагина из первой статьи. По этой причине я в конце каждой своей публикации про idea-плагины оставляю ссылку ну репоизиторий idea-community. Собственно тут я и решил задокументировать свой опыт, если кому то еще понадобится.
Если интересно то начиная с версии 232.7 добавлена поддержка Kotlin JVM
Как я уже говорил в статье, что пока проект в стадии MVP и много кода я заимствовал из основного репозитория idea-community. Поэтому все что можно было переиспользовать я оставлял как есть. Но новый код я пишу на Котлин (лично для себя я не вижу тут большой проблемы, да и в JB никто не заставлял писать на чем то конкретно). Но учитывая что при каждом релизе IDEA, даже мне приходиться местами переписывать код, т.к. ломается обратная совместимость (поэтому у меня уже в репо появились ветки 222/223/231/232), а ваш форк имеет еще более раннюю кодовую бд, то даже код на Java не получилось бы скорее всего легко адаптировать под него и пришлось бы многое переписывать. В основном переписывать надо будет конвертеры в External API - MavenProjectResolver и в взаимодействие с Maven GServerHelper. Можем обсудить детали в лс, если будет время я готов помочь.
Начиная с версии 3.3.1 минимальная версия JDK 7+. И я посчитал что почти 10 лет это срок) поэтому также своему Maven плагину поставил минимальную версию 7. Также начиная с 3.3.1 есть ряд фич на которые есть завязки в коде - например .mvn/jvm.config. Но в целом это не мешает запускать проекты и на более ранних версия Maven, если они работают на JDK 7+. Интереса ради проверил на версии - 3.2.1 все ок. Но вот на 3.1.1 уже вылезли проблемы несовместимости API MavenSession.
https://maven.apache.org/docs/history.html
Я не против, open source же) главное чтобы продукт развивался и становился лучше)
Пока никак, т.е. специально для этого я ничего не делал. Но как показывает практика - все не так уж и плохо) Если сгенерировать Maven/Kotlin проект через стандартный wizard и далее открыть моим плагином, то он с большой долей вероятности заработает на дефолтных IDEA Kotlin Compiler настройках. А Maven вернет корректную проектную модель с Kotlin content root’ами, благодаря параметрам - <sourceDirectory>/<testSourceDirectory> из билд файла - и все будет работать в IDE. Если создать Spring/Kotlin/Maven проект через spring initializr, то там будет еще проблема при билде проекта из IDEA, т.к. она ничего не знает про kotlin-maven-allopen. Но если сбилдить проект мавеном - package, то он сгенерит в target уже корректные “открытые” классы и все далее будет прекрасно работать в IDE. Надо будет кончено допилить эти моменты, займусь в ближайшее время)
Я еще подумал над вашим кейсом - использование дополнительных maven-task при импорте. И нашел одну неприятную особенность, сейчас так задумано что ‘maven agrs’ передаются по все внутренние процессы плагина, будь то импорт проектной модели или запуск таска. И при запуске тасков это выглядит избыточно, особенно при clean. Основной вариант использования(по моему мнению) mvn agrs - это переопределение стандартных настроек Maven во всех процессах плагина (кастомные сеттинги -s /home/settings.xml, локальный репо -Dmaven.repo.local=/home/my_repository и прочее). Поэтому я решил сделать отдельную настройку ‘Import args’ для указания дополнительных аргументов, который будут использоваться только при импорте.
Будет вот так (в ближайшее время выложу новую версию в основной Marketplace, уже не alpha):
Additional args - будут добавляться во все maven процессы, включая импорт. Основное назначение переопределять во всех процессах базовые Maven параметры. Для частных случаев можно создать Run Configuration.
Import args - только для импорта.
Потому что плагины для IDE не пишутся с чистого листа. Для IDEA плагинов есть свой шаблон, встроенный в стандартный wizard. Который использует Gradle и обеспечивает базовый флоу написания плагинов - их запуск, отладку, публикацию в marketplace и прочее. И заниматься изысканиями на тему, а можно ли это переделать на Maven, я не видел смысла, т.к. решал совсем другую проблему.
Тем более официальная документация не дает альтернатив. А поиск решений для Maven, находит только не активные проекты вроде - https://plugins.jetbrains.com/plugin/7127-intellij-plugin-development-with-maven/versions и https://maven.apache.org/plugins/maven-idea-plugin/
Спасибо за обратную связь! Интересный use case. Еще одно доказательство того, что нет ничего лучше чем полноценный maven lifecycle для импорта проекта) Если найдете какие то проблемы, то смело пишите в лс. А как раньше вы работали со своим проектом - Eclipse?
GMaven Plus это плагин для Maven.
Мой GMaven это плагин для IDEA. И с аналогичным именем в IDEA Marketplace других плагинов нет. К тому же я не уверен что имя плагина должно быть уникальным, в отличии от plugin id.