LINUX.ORG.RU
ФорумTalks

давно за яву не терли?

 ,


1

2

spring хотят решительно все (hh.ru по слову spring не даст соврать). spring везде, в тебе и во мне. spring spring spring!

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

автомагически, где-то что-то кому-то вроде наинжектилось, но где что и кому...? а если часть еще и в конфигах... найти тот заветный конфиг, который отвечает за нужный кусочек --- это большая удача, нежели закономерность.

сказка просто.

это я старпер старовер, да...? спринг --- то самое, светлое, которое «нужно» или что-то опять пошлО не так?

Перемещено tailgunner из development

★★★★

Последнее исправление: Rastafarra (всего исправлений: 1)

spring хотят решительно все

4.2

автомагически, где-то что-то кому-то вроде наинжектилось, но где что и кому...?

Ну да, спринг гогно, но только вот та же ситуёвина с любым DI, ибо «извращение зависимостей».

Deleted
()

Java божественна. Spring божественен.

Subj.

SaBo ★★
()

xml конфигов в спринге уже давно нет. И хотят его года так этак с 2008 абсолютно все.

Что сказать хотел, непонятно.

Deleted
()
Ответ на: комментарий от Deleted

На jpoint, кажись, было ржачное (для тех кто в теме) видео, где ребята целый час рассказывали как завести юнит тесты с этой шнягой.

Deleted
()

Да нифига, терпеть не мог никогда это legacy, этот ад. Жирное уг. И еще это г тянули во всякие Flash/Flex, типа клоны Spring на ActionScript, с этими упоротыми фабриками фабрик, которые пишут индусы, а русским потом разгребай конюшню. Плавали, знаем.

menangen ★★★★★
()

Микросервисы спасут тебя. Не делай проекты больше 1к строк или где больше двух либ в зависимостях (кроме самого спринга, jackson'а и rabbitmq).

crutch_master ★★★★★
()

спринг --- то самое, светлое, которое «нужно» или что-то опять пошлО не так?

Библиотека качественная, решает насущные проблемы, её все знают, что может пойти не так?

Legioner ★★★★★
()

re: выбешивающще из-за тонн xml

Как относительно старый {xml,java}фоб, замечу, что ничего не мешает же генерить эти xml-и из описания на каком хочешь другом языке. Ну, кроме лени. И тогда ты не поцарапаешься xmlем, может быть даже не глубоко вступишь в жаву. И наверняка будешь точно знать, где что искать. Или нет.

DonkeyHot ★★★★★
()

XML избыточен. XML не нужен. Как и не нужно все, что касается жава. А коли жава касается всего - то все не нужно. Дзен.

Siado ★★★★★
()
Последнее исправление: Siado (всего исправлений: 1)
Ответ на: комментарий от Legioner

Есть, но он не нужен. Кодом удобней.

Deleted
()

Spring был призван заменить Java EE 1.4 (EJB 2.1, JSP 2.0 без JSTL и JSF). Но уже есть Java EE 8 (EJB 3.2, JPA 2.2, JSF 2.3) и готовится EE 9, так что Spring исчерпал свою миссию и фактически не нужен. Для него продолжают писать только олдыри и студни, которые учатся на их заблуждениях.

iZEN ★★★★★
()

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

неосилятор поиска в ide?

Nirdosh
()

spring хотят решительно все

обхожусь без него, и желания особого нет, hibernate достаточно.

barberry ★★
()

спринг --- то самое, светлое, которое «нужно» или что-то опять пошлО не так?

Это который до смешного медленный и жирный?

RazrFalcon ★★★★★
()
Ответ на: комментарий от Legioner

Библиотека качественная, решает насущные проблемы, её все знают, что может пойти не так?

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

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

никто не станет на пароходе возить картошку с дачи.

barberry ★★
()
Ответ на: комментарий от RazrFalcon

Он, строго говоря, не медленный. Задача спринга, насколько я понимаю, связать во время запуска бины - и всё. Остальные тормоза на совести говнокодеров. А вот с «жирный» трудно не согласиться.

crutch_master ★★★★★
()
Последнее исправление: crutch_master (всего исправлений: 1)
Ответ на: комментарий от Nirdosh

Скорее нищеброд любитель IntelliJ Community Edition, в которой этого нет.

bbk123 ★★★★★
()
Ответ на: комментарий от RazrFalcon

Ты никак не поймёшь, что у больших фреймворков задача не в обеспечении максимальной скорости. И не каждому проекту нужна эта скорость. Так как Java == Enterprise, там больше про обработку данных и всякие хитрые штуки, где гигабайты бизнес логики в исходниках. Вот у тебя бывало такое, что сайт быстрый, но ты там жмёшь какую-нибудь кнопку и оно долго думает? Это оно. Например, накопилась какая-то статистика, терабайты в БД. И вот манагер заходит в веб-морду, жмёт кнопку, терабайты полчаса распределённо обрабатываются как ему надо. Вот какие задачи у кровавого ынтырпрайза, который на Java. Поэтому и джавовские фреймворки такие. Хватит в каждой теме говорить, что «молоток лучше», когда там спрашивают про завинчивание шурупов.

InterVi ★★★★★
()
Ответ на: комментарий от Deleted

ты б меня кастанул. Это вопрос «есть ли жизнь после ЛОРа».

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

поэтому я понял, что надо расширяться и увеличивать аудиторию Java от сотен до сотен тысяч людей

поэтому я теперь топовый блогер хабры (продержал и свой профиль и профиль компании #1 в рейтинге прошлую половину года), редактор сайта http://jug.ru, девался на подкаст http://razbor-poletov.com, на конференции наши (например, на https://jokerconf.com/), на фейсбук (в профиле), время от времени читаю доклады (например, вошел в top-10 JEEConf Kiev этой осенью с докладом по GraalVM).

со следующего месяца задача вывести http://jug.ru на сто тысяч уников в месяц. Честно говоря, я хотел того же самого для джава-статей на лоре, но раз нет, то нет. Будем работать с тем, что есть.

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

stevejobs ★★★★☆
()
Последнее исправление: stevejobs (всего исправлений: 1)

Spring это просто космос, детка.

А JavaEE зато сдохла (переродившись в JakartaEE, где они мгновенно увязли в конвертинге проприетарщины в открытое и создании рабочих групп, но всё это без денег Оракля уже). Что тоже скорее хорошо.

stevejobs ★★★★☆
()
Ответ на: комментарий от InterVi

гигабайты бизнес логики в исходниках

Это такой тонкий вброс на тему «на java лаконично не напишешь»?

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

kawaii_neko ★★★★
()
Ответ на: комментарий от nerfur

Я просто боюсь, что не смогу ещё и текстом делать. Там же в основном будут всякие скринкасты вида «глядите какую фигню добавили в Spring Cloud Data Flow 1.6 alpha 2». Текстовые расшифровки скринкастов - это очень большая сложная работа, которая может занимать по целому дню.

Сейчас мы с «разбором полётов» делаем дайджесты наоборот. Я вначале пишу дайджест, а потом мы его голосом проговариваем. Но даже написание дайджеста требует несколько часов - там в фиде больше тысячи постов в RSS и несколько тысяч в твиттере, надо всё это прочитать и фильтрануть. Открыть статьи, вычленить из них текст, попробовать сформулировать максимально коротко. У меня есть для этого классификатор для microsoft cognitive services, но он пока не справляется, приходится руками. Потом всё это вычитать на предмет русского языка, провести факт-чекинг, сверстать для вордпресса. Потом собрать чуваков и записать подкаст. Потом раскидать по телеграм-каналам и соцсетям. Потом обсудить это всё в телеграме с подписчиками. Всё вместе - полдня точно.

stevejobs ★★★★☆
()
Последнее исправление: stevejobs (всего исправлений: 3)
Ответ на: комментарий от barberry

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

Что в этом плохого? Места на диске жалко?

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

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

никто не станет на пароходе возить картошку с дачи.

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

Legioner ★★★★★
()
Ответ на: комментарий от Miguel

Фреймворк, латающий дыры в языке Java, отчего писать на Java становится легко и приятно. И набор из нескольких сотен проектов (библиотек, фреймворков), в основном инфраструктурных, совместимых с этими расширениями.

stevejobs ★★★★☆
()
Ответ на: комментарий от menangen

упоротыми фабриками фабрик, которые пишут индусы

больше паттернов богу паттернов. чтоб мониторы гнулись от оопнутости.

i36_zubov
()
Ответ на: комментарий от stevejobs

Сейчас мы с «разбором полётов» делаем дайджесты наоборот. Я вначале пишу дайджест, а потом мы его голосом проговариваем.

По-моему, «Разбор полётов» занимается только тем, что обсуждают свежекупленные Макбуки и поносят Java. Ничего интересного про Java сейчас там нет - только какой-то сырой Kotlin продвигают на хайпе и Кубернетес с глючным Докером обсуждают. То есть эта кампашка выступает в прямом смысле ПРОТИВ использования Java и ЗА использование JavaScrip-технологий (со всеми вытекающими гигабайтами жора оперативной памяти) и сырых коммерческих продуктов.

iZEN ★★★★★
()
Ответ на: комментарий от stevejobs

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

Скальные новости будешь включать или там интересные статьи из мира Scala/других жвм языков?

nihirash ★★★
()

spring хотят решительно все

Блокчейн и ML тоже все хотят, и что? Ни одной из этих хайповых шарашек через год не останется. Вакансий с нормальными языками и фреймворками меньше не становится.

slovazap ★★★★★
()
Ответ на: комментарий от kawaii_neko

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

На это всё надо смотреть в историческом контексте, 90-00. Тогда кроме Java нечего было выбирать:

  • кроссплатформа из коробки (киллер-фича на те времена)
  • производительность между нативными сями и скриптотой, вполне высокая
  • простой синтаксис, экономящий время разработки
  • GC, экономящий время разработки
  • легко дебажить, опять экономия (вот поди подебажь си с его сегфолтами)

У неё просто не было достойных конкурентов. Конечно можно и на сях писать, только вот проекты то большие, это сильно больше багов (хотя бы из-за ручного управления памятью), дольше по времени, сложней. А зачем тратить $N, если можно тратить меньше?

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

На любом языке можно писать лаконично, когда это твой личный проект или open source, где никто особо не подгоняет. Но на больших коммерческих проектах это трудно, потому что горят сроки и потому что 99% кода уже написано индусами, никто не даст тебе его переписывать, потому что тогда надо заново проводить полный цикл тестирования. За то и платят джаверам, чтобы они копались в говнокоде и костылях, запиливая сложную бизнес-логику.

Потому Java EE / Spring / etc - это не быстро ехать. Ну купят новое железо если тормозит, делов то. Месячная зарплата кодера дороже выходит и всё равно он не разгонит терабайт исходников даже за несколько лет.

К сожалению, такие простые вещи почти никто не понимает из тех, кто пишет open source в свободное время, тратя месяца своей жизни на вылизывание кода. Ну хоть бы разные конференции на ютубе смотрели, информация же открытая. Или хоть бы описания к фреймворкам читали, для чего они вообще делаются. По спорам складывается такое впечатление, что сморят люди, крайне далёкие от реальной разработки.

InterVi ★★★★★
()
Ответ на: комментарий от icefreeze

Задача фреймворков - сократить время разработки. Потому что от их функционала всё равно никуда не денешься, нет смысла каждый раз писать его заново. Подключаешь Laravel, у тебя там роутинг, авторизация, шаблонизатор, ORM, БД, модули всякие - берёшь их быстро пишешь что тебе надо, вместо того чтобы изобретать собственный велосипед. Если проект маленький, лучше брать микрофреймворк, или подключать только нужное (Symfony так умеет).

InterVi ★★★★★
()
Ответ на: комментарий от InterVi

Ну купят новое железо если тормозит, делов то

А теперь спроецируй это на себя: тормозит браузер? Купи новое железо! Тормозит linux? Купи новое железо! etc

Жабокопрокодеры — движущая сила мировой экономики!

kawaii_neko ★★★★
()
Ответ на: комментарий от kawaii_neko

За новые возможности нужно платить производительностью, это неизбежно. Глупо сравнивать современный софт с поделками из нулевых, когда каждый байт экономили.

InterVi ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.