Встреча для Java-разработчиков: говорим про асинхронные микросервисы и опыт создания большой билд-системы на Gradle

С ВЕРТЕКСА НА СПРИНГ???

Да, это уже конкретный приговор ява-разработке...

Жаль, что в это время у меня будет отпуск и я буду в другом городе :(

Java

микросервисы

Как нечто, потребляющее десятки ГБ памяти, может называться «микро»?

Точно также как незнание матчасти не мешает тебе неумело троллировать.

а бывают синхронные микросервисы?

конечно

Gradle?!

Gradle — это боль.

Говорите о ней сами.

Все билд-системы в той или иной степени дрянь. Вы знаете что-то получше градла?

А можно ли считать ядро Linux набором синхронных микросервисов?

Что не так с Gradle? Мне он вкупе с Groovy показался гораздо удобнее, чем ужасный Maven с этими XML из прошлого века.

gnu make :D

ДА! Осталось только спортировать его на грейдл с вставками на вызовы анта + платформенный асм и дт билдить нинзей в докере!

Иногда проще написать билд систему на бусте чем на груви :)

В тот момент когда генерация дерева построения начинает переваливать за 15-20 минут начинаешь о таком задумываться...


Когда перевалила за 40 - просто переписываешь :) Мейнтенанс правда болезненный, но задо грязные лапы девов больше не копипастят грувотины из интернета в конфиг. А «сигнификант редакш оф препроцессинг тайм ап ту фифти таймз» звучит убедительнее криков навомодных SO-погромистов.

Все билд-системы в той или иной степени дрянь. Вы знаете что-то получше градла?

Вызывать из Maven код на Java в узких местах. Или полностью запилить плагин для Maven. Попробуйте это довольно просто для миддла.

Что не так с Gradle?

Он тормозной и переусложнён.

Maven с этими XML из прошлого века.

Можете использовать JSON или даже придумать свою систему разметки, например YAML транспилить в JSON или XML.

rake

Иногда проще написать билд систему на бусте чем на груви :)

Проблема всех билд систем в том что ими пользуются разработчики.

А разработчики не умеют _пользоваться_, они умеют только писать код. Поэтому вместо того чтобы узнать как устроена билд-система, под какой принцип организации кода заточена, и как оптимально её использовать, они в неё пишут, на груви с вставками из java-кода.

И там где достаточно было бы положить файлы компонента в папочку components чтобы gradle их подобрал, автоматически корректно интерпретировал и встроил в процесс, разработчик пойдет писать плагин, или скорее inline-скрипт, который пойдет собирать компоненты из 5 разных мест включая tmp/test/do-not-merge/component, потому что ему так удобнее.

Он же разработчик, это не он подстраивается под систему, а система подстраивается под него.

А потом да, из-за этих inline-вставок всё ломается при каждом шевелении, про кроссплатформенность можно даже не начинать. Но это же билд-система виновата.

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

А как надо многокомпонентную сборку сделать с запуском тестов в определенном порядке, так я прихожу со ссылками на гредловые параметры из гайда и говорю что мол надо проапгрейдиться до gradle 4.0 у нас это всё будет из коробки, только вот здесь структуру каталогов поправить.., а мне «а я вот тут за вчера набросал на groovy, всего 85 строк, правда я не понял куда вот этот callback смотрит, но у меня работает». И сеньор ведь, архитектор практически.

Простите, наболело.

У меня есть на эту тему гипотеза. Микросервисы очень популярны у явистов, потому что они типа считают, что ява-монолит превращается в гуано. Но они думают что это потому, что монолит :-) а я вот подозреваю, что это потому, что ява...

Или яву не юзать

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

Микросервисы очень популярны у явистов

Микросервисы популярны у хипстеров. В ноджс им обмазываются с ног до головы, но там и хипстеры каждый первый. В джаве их тоже хватает, но они более прорежены.

«Нажмите любую другую клавишу»

Смотря для чего, но в целом всё что угодно - нода, го, пхп, питон...

нода, го, пхп, питон...

Мдя, я думал окажешься поумнее, хотя бы C# предложишь.

Тут соглашусь. Но как-то всё равно много адептов бродит и про msa именно в контексте явы вещает

C# это те же яйца что ява, только в профиль. Ну язык немного поприличнее, там хотя бы var есть и перегрузка операторов. Но что-то я не вижу тонн популярного опенсорса ни на яве, ни на C# - а вот на go сколько хочешь как раз

что-то я не вижу тонн популярного опенсорса ни на яве

https://github.com/search?q=language:java stars:>50&type=Repositories 23,996 repository results

а вот на go сколько хочешь как раз

https://github.com/search?q=language:go stars:>50&type=Repositories 10,268 repository results

Посмотри внимательнее. Сделал фильтр на больше 50 звёзд. А то go совсем уж нищебродом окажется, если убрать фильтр по звёздам.

Можно даже убрать Android https://github.com/search?q=language:java stars:>50 NOT android&type=Rep... Чтобы сделать сравнение честнее, но всё равно в 1.5 раза больше проектов.

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

т.к. по-моему самый популярный софт на джаббе - это IDE для самой джаббы.

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

просто на ум с go сразу приходит как минимум docker и gogs, а на ум с явой не приходит ничего. точнее, ну есть и на яве веб-гуй для гита, gitblit, я его даже юзал пару лет и в итоге он меня задолбал, потому что на яве, тёк, падал и т.п.

ну правда есть эластик и кафка, да - тут засчитано =)

ну в общем не знаю. у нас на работе понаписали уже этих «микросервисов на спринге». с тех пор у меня стойкая антипатия и к микросервисам, и к яве.

я как раз было думал что vert.x их возможно спасёт. а тут уже доклады про то, как люди с vert.x обратно на spring переходят. кошмар. лучше бы сдохла эта ява давно. зачем её гугл спас выпуском андроида...

меня интересует именно популярный софт,

Т.е. тебя интересует прикладной софт? В этом у джавы проблемы, да.

не включая библиотеки и фреймворки для самого языка и IDE для самого языка

Так это самое важное для бекенд разработки.

т.к. по-моему самый популярный софт на джаббе - это IDE для самой джаббы.

Ну вот видишь, есть популярный софт, причем прикладного назначения? Только IDE пользуют не только для джавы, для всех ЯП считай есть плагины. И они очень популярны.

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

Выпилил, смотри пост выше, всё равно в 1.5 раза больше репок.

с go сразу приходит как минимум docker и gogs

Мне не приходит, я вообще не знаю что такое gogs. А docker я вообще хз на чём написан. Да и не и пользуюсь я этим поделием.

docker на Go как раз. Go этим и уникален - с одной стороны простой и веб-френдли, с другой - компилируемый в бинарь, интегрируемый с C-ями, и пригодный для системного ПО. хоть синтаксис и бешеная помесь C и питона...

с другой - компилируемый в бинарь, интегрируемый с C-ями, и пригодный для системного ПО

Джава сегодня также умеет. И var подвезли, хотя за var я бы убивал.

с одной стороны простой

Мне не нужен простой ЯП для написания хелловордов, мне нужен удобный ЯП для разработки больших проектов. Поэтому Go как альтернатива джаве не подходит.

Спринг же небось все равно так не соберешь. А без спринга никто уже шага ступить не может

Проблема (сугубо личное мнение) в том, что сложный проект на яве раздувается и становится еще сложнее. Если то же написать даже на пхп! - кода будет меньше и он будет проще, а соответственно легче сопровождаемый.

Не, я не говорю про какие нибудь очереди типа кафки. Их ясно что ты на пхп не очень перепишешь (хотя можешь на го, наверное). Но корпоративный говнокод среднего пошиба, который в 95% на яве и пишут, по моему, по сути проще писать НЕ на яве. Проще - в смысле код в итоге проще.

Спринг же небось все равно так не соберешь.

Насколько знаю не соберёшь, фичу еще допиливают. Но для бекенда в этом нет смысла. А сделать cli утилиту или системное ПО без проблем.

А без спринга никто уже шага ступить не может

Ну это проблема не джавы, а фреймворков. Сам ЯП не запрещает сделать для него качественный и современный фреймворк.

по сути проще писать НЕ на яве

Может и проще, только написать код это полдела. Потом встаёт вопрос простоты его поддержки и доработки. И вот здесь джава делает всех.

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

Вот только зачем мне эти франкенштейны, когда есть джава, и в которой давно это уже всё есть? Причем всем комплектом сразу.

достойную альтернативу

Ну-у-у туда Ржавый пытается залезть. Но пока только пытается.
Нормального стек только нарабатывается, хотя подвижки есть.

Если бы они сделали сахар для ООП, чтобы та же реализация DOM на ржавом не выглядела уродливо, то я бы еще вчера перешел на ржавый. Ждал я это пару лет, потом плюнул.

Ну-у-у туда Ржавый пытается залезть

Кстати, уже не успеет. По джавому роадмапу очень много вкусностей для низкоуровщены подвозят. Год-два и это будет доступно в JDK. После чего с джавы еще сложнее будет переманить на что-то новое.

Я уж не говорю о новых GC, которые не сравнить с тем, что было раньше.

Там нет жесткой структуры в отличие от мавена, где всё по xsd схеме. И в результате его пишут кто во что горазд, каждый билд файл может иметь совершенно разную структуру. А мавен держит всех в рамках и предсказуем, открывая новый проект всегда знаешь где смотреть.

ужасный Maven с этими XML из прошлого века

У XML хотя бы были DTD и схемы, т. е. гораздо труднее написать то, что не работает, и гораздо лучше автодополнение во вменяемой среде.

У Gradle серьёзные проблемы со стабильностью интерфейсов (даже в пределах одной ветки релизов, напр., 4.x или 5.x), а также тем, что Groovy – динамический язык (т. е. вот написал, как советует очередной рецепт со SO, вот оно даже молча отрабатывает, но, с%ка, не работает). И зёрна сакрального знания можно найти на тематических форумах, но зёрна эти устаревают в течение полугода.

По поводу стабильности интерфейсов – в качестве демонстрации, попробуйте написать мало-мальски функциональный модуль расширения, и попробуйте добиться, чтобы он одинаково хорошо работал одновременно хотя бы на 5.0 и 5.4.х. И Вы меня поймёте.

По поводу Groovy – дела стали несколько лучше с появлением Kotlin DSL (.kts), но всё по-прежнему не идеально. Когда нужно сделать шаг влево или вправо, снова приходится шарить по исходникам DSL, матерясь про себя и ища очередной чёртов extension method. Здесь стоит заметить, кстати, что Kotlin tooling не идеален даже в IDEA, а в альтернативных средах разработки использование проектов на Gradle превращается в ад.

Да, у Gradle действительно есть плюсы вроде параллельной и инкрементной сборки (т. е. из консоли оно зачастую собирается быстрее), но в результате на проекте из 20-30 модулей я теперь по 2-3 минуты жду, пока IDEA при окрытии соблаговолит построить проектную модель.

P. S. И ещё я неоднократно видел, как неофиты-хипстеры (любители всяких docker’ов и проч.) пихают свой build.gradle в т. ч. для автоматизации обычных админских задач, т. е. стартуют JVM даже там, где нужно просто скопировать файл – просто потому, что не осилили make. Адепты Maven, по моему опыту, таким не страдали.

Вы знаете что-то получше градла?

Лучше или хуже в данном случае – вопрос субъективный.

Единственным объективным критерием может служить кол-во затраченных человекочасов. Я не первый год работаю с Gradle (и не первый десяток лет с JVM) – и порой ловлю себя на том, что на инфраструктурные задачи (забабахать очередной скриптец на Kotlin DSL) трачу времени больше, чем собственно на написание кода.

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

Там нет жесткой структуры в отличие от мавена, где всё по xsd схеме. И в результате его пишут кто во что горазд, каждый билд файл может иметь совершенно разную структуру. А мавен держит всех в рамках и предсказуем, открывая новый проект всегда знаешь где смотреть.

Вот неистово плюсую.

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

Наоборот все нормальные люди уже с явы слезли на все что угодно другое. Это только корпорасты все пытаются труп реанимировать.

В джаве точно так же срисовывают с js - var и кложуры. Потому что SystemZhopaArgumentOutOfBoundsException всех немного задолбало писать, длинновато, знаете ли. «Но зачем мне жава когда это все давно есть в js», ага)

Ну не кормите его, ну пожалуйста :).
Если человек не сталкивался с крупными корпоративными решениями, которые тесно интегрируются с другими системами и работают с важной информацией, то ему будет сложно объяснить, почему Java/C#.
А уж если человек пришел потроллить, то и подавно.

Решениями, хосспаде. Говнокод говнокодом в 99% случаев

Адепты Maven, по моему опыту, таким не страдали.

Страдали. У нас постгрю в докере из мавена для тестов поднимали.

и подкрепимся пиццей

А пища то не здоровая...стыдно, товарищи.

Кода в 5 раз больше чем надо

Кода как и везде, с чего бы ему быть в 5 раз больше?

и еще кривожопая магия спринга на каждом углу.

Не используйте спринг, есть другие хорошие фреймворки.

Лучше уж на пхп писать.

Так его уже от джавы не отличишь, всё слизали под чистую.

Наоборот все нормальные люди уже с явы слезли на все что угодно другое

Пруфы давайте. Или как и с опенсорц проектами? Мне за вас пруфы искать и показывать, что всё как раз наоборот?

Это только корпорасты все пытаются труп реанимировать.

Первый ЯП по популярности, максимум второй (после жс, если судить по гитхабу), ну ок )

В джаве точно так же срисовывают с js - var

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

и кложуры

Вот это точно не жс был первым.

Потому что SystemZhopaArgumentOutOfBoundsException всех немного задолбало писать

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