Розробка · 25 липня 2014, 23:58 9066

Gabriel Angelos, Groovy/Java Developer в startup

Горький вкус Java

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.

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

Я уже предчувствую велостоянку или даже целый велотрек из поделок: контроллеры/DAO/формы и гениальные утилиты по парсингу даты из формата в формат и все это практически с нуля. Grails мог бы сэкономить 80% времени разработки, но нам его использовать не дадут, потому что заказчик считает Groovy детским развлечением и готов платить в 5 раз больше, или его убедили в этом. NoSQL база и хранить объекты в JSON, отказ от hibernate-ов и сокращение разработки еще на 40%? Ни в коем случае, заказчик хочет переиспользовать свой SQL-server и «решения» под него из подпорок и костылей...

Почему при разработке на Java всегда тяжело и всегда испытываешь страдание? Ну например сваять простенький интернет-магазин. Знакомые PHP-шники смеясь делают за 1-2 дня, в то время как нам требуется месяц. Небольшая система, которую я один написал бы на Groovy за 7 дней в команде из 3-х человек на Java занимает полгода. Я думал над этим все эти годы и не понимаю причины...

Почему Java жрет так много памяти? почему для средненького проекта нужно 1-2гб выделить под Heap, а на моем текущем используется 128 гб RAM облака и 8 процессоров...

Почему сам язык настолько беден и неуклюж? Почему работы с датами/потоками/коллекциями вызывают недоумение и неудобство. Поэтому на каждый чих — dependency, получаем на выходе гигантский артефакт/-ы и постоянные конфликты транзитивных зависимостей...

Почему 95% задач формошлепство или двиганье кнопочек? Неужели недостаточно уже существует подобный систем, что нужно создавать новый хаос, обкладывать функционал кучей work-around-ов. Но нет, взять готовую CMS-ку не с руки, всем нужно оживить их франкенштейна и пришить ему еще одну конечность...

Я разочаровался в Java как в языке так и в диаспоре/проектах под нее, думаю плотно переключаться на Scala и расти под нее.

Теми: Java

👍ПодобаєтьсяСподобалось0

До обраногоВ обраному0

Facebook

Twitter

LinkedIn

Найкращі коментарі пропустити

Pavel Kruchina 26.07.2014 10:41

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

Проблема нашей отрасли в том, что инструмент выбирают по принципу «что хочет заказчик» или «что есть в сарае». Ну уж никак не «какой инструмент из всех существующих в нашем мире лучше подойдет для решения данной конкретной задачи».

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

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

Перейти до дискусії

Ctrl + Enter

Ctrl + Enter

Нестор Иванович 24.09.2018 00:23

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

Відповісти

Підтримати

Włodzimierz Rożkow інфлюенсер в t.me/full_of_hatred 24.09.2018 00:07

Пацан, переїжджай на Rails/Grails, сам джавакодив багато років, пересів на Rails—волосся стало густішим та блискучішим. Брат живий, залежність є. Назад повертатися не хочу, але час від часу маю тому що саппорт. На java-девелоперів які там тілібонькають контролери з сервісами та пишуть даошечки тепер шкода дивитися.

Прогресу в нас (java) немає і не буде.

Чому така мова—тому що робилась спеціально щоб індуси могли девелопити ентерпрайз в ентепрайзних масштабах.

Відповісти

Підтримати

Антон Харуйманов 28.08.2014 18:06

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

По теме: с Джава-смежным стеком технологий легче всего найти работу за границей.

Відповісти

Підтримати

Васисуалий Лоханкин 30.07.2014 23:12

примерно как в анекдоте, когда Рабинович по телефону напел Битлз

Відповісти

Підтримати

Maxim Kozenko Стейкхолдер в FONDY 30.07.2014 00:55

Grails мог бы сэкономить 80% времени разработки, но нам его использовать не дадут, потому что заказчик считает Groovy детским развлечением и готов платить в 5 раз больше, или его убедили в этом.

Может потому что архитекторы в крупных компаниях-заказчиках тоже люди и тоже хотят кушать и кормить семью красной икоркой. А на опенсорс проектах сильно не разбогатеешь. В нашем проекте в одном крупном европейском банке оба архитектора ездили на авто класса порш кайен. Возможно потому что продвигали в банк продукты oracle (например GoldenGate которые никак не могли взлететь из-за проблем с нагрузками), а возможно просто талантливые — это мое субъективное мнение

Відповісти

Підтримати

mobile mobile 30.07.2014 01:15

у меня счас один свежепризванный деятель уже 7 месяцев внедряет Microstrategy, потратили уже гдето 400к и конца края не видно. Сначала сдвинули с Мая на Июль, потом на Сентябрь. Без всяких диаграмм ганта, без всяких тренигов команде которая внедряет ( два чела которые и SQL плохо понимали вначале). Все это снабжается рассказами что боссам нравятся графики и босы ждут не дождутся посерфить статистичку с айпада, боссам он тоже что то красивое впаривает и требует увеличения бюджета потому что нада нанять экпириенсед инженера для завершения вовремя, а это где то еще 12-18к в месяц. Я так думаю — это талант свистеть и какой то личный интерес боссов.

Відповісти

Підтримати

Ще 2 коментарі

Maxim Kozenko Стейкхолдер в FONDY 30.07.2014 01:26

Мы сейчас в нашем проекте тратим $300 на хостинг серверов (пока нет нагрузки, обходимся амазоном с medium инстансами), все остальные затраты IT — это зп разработчиков. Но какой вменяемый босс поверит, что серьезный проект может так дешево стоить? Конечно же его проще убедить на $400к чем $3к

Відповісти

Підтримати

reality_hacker 30.07.2014 02:48

И че, вы микростратегию за пару месяцев наклепали? Думаешь твой пример релевантен?

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 30.07.2014 07:53

А на опенсорс проектах сильно не разбогатеешь. ... Возможно потому что продвигали в банк продукты oracle

Если че, за Grails стоят SpringSource/Pivotal или глубже EMC/VMware. Так шо не надо про кайены.

Відповісти

Підтримати

Gabriel Angelos 30.07.2014 21:19

Может потому что архитекторы в крупных компаниях-заказчиках тоже люди и тоже хотят кушать и кормить семью красной икоркой.

Вы пытаетесь оправдать коррупцию? А иначе проталкивание инструментов за откаты/преференции и назвать нельзя.

Відповісти

Підтримати

Ще 10 коментарів

mobile mobile 30.07.2014 21:36

это не коррупция, это выбивание бюджета из компании под личные амбиции

Відповісти

Підтримати

Gabriel Angelos

Gabriel Angelos 30.07.2014 21:39

Вы договаривайте, если Oracle продаст свой SAP за 10 млн$ данной фирме, то чувак за это черную икру не получит, ну не обменяют в магазине чувство благодарности на икру. А вот если Oracle отблагодарит...я думаю именно это он и имеет ввиду.

Відповісти

Підтримати

mobile mobile 30.07.2014 21:41

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

Відповісти

Підтримати

Gabriel Angelos

Gabriel Angelos 30.07.2014 21:43

Если все так прозрачно и честно, то за какой счет он покупает икру?

Відповісти

Підтримати

mobile mobile 30.07.2014 21:51

большая зарплата, плюс годовой бонус, плюс инвестиции. В основном это конечно инвестиции, но для них нужны первые два пункта. Что бы ездить на порше в европе нада гдето от 7к евро чистыми получать если у вас уже есть где жить. Можно и меньше конечно, но тогда он будет не сильно новым. зарплат от 7к евро чистыми в европе есть, но очень мало, как правило это контракторы в очень востребованных сферах или топ менеджмент. даже при 7к евро за 20 лет карьеры (считаем что вы вышли на 7к в 30 лет) вы заработаете около 1,7 ляма евро и сохранить сможете около ляма включая недвигу шутк на 700, тоесть у вас будет в кеше около 300к евро что в принцепе хватает, но не на икру. А вот если вы начнете инвестировать в акции или еще там во что то то за 10 лет под 10 процентов вы сможете удвоить сбережения, а если повезет то и утроить и упятерить. Вот тут уже можна будет и икры поесть.

Відповісти

Підтримати

Gabriel Angelos

Gabriel Angelos 30.07.2014 21:53

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

Как это связано с использованием Oracle vs open-source? Или бонус платится исходя из этого?Не растекайтесь мыслью по древу со своими фантазиями про миллионы и недвижимость.

Відповісти

Підтримати

mobile mobile 30.07.2014 22:01

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

Відповісти

Підтримати

Gabriel Angelos

Gabriel Angelos 30.07.2014 22:07

Получается компании понесут большие расходы на такие решения. Где им еще взять большие бонусы и более высокую з.п. для своего менеджера по сравнению с open-source?

Відповісти

Підтримати

Нестор Иванович 01.08.2014 01:02

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

Відповісти

Підтримати

mobile mobile 01.08.2014 01:09

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

Відповісти

Підтримати

Нестор Иванович

Valentin Serduk Technology Manager 31.07.2014 14:04

Фиг его, внедряю опенсорс в банке, все ок. Распил-откат это же скучно, не? Проблема в том, что обычно внедрение опенсорса это горящие глаза и «все будет круто!». А манагеры, которые в крупных компаниях, обычно цифры понимают. Когда ты им посчитаешь кейс и в цифрах покажешь выгоду, то, как правило, тебе дают зеленый свет и пили что хошь.
Резюмируя — проблема опенсорса в том, что обычно люди, которые его внедряют, не умеют его п(р)одать, а не в том, что он опенсорсный и денег не попилишь.

тут еще есть ньюанс, что опенсорс-адепты пытаются его воткнуть везде, зачастую и туда где он вреден и не нужен

Відповісти

Підтримати

Ще 1 коментар

undefined pointer 31.07.2014 14:34

обычно люди, которые его внедряют, не умеют его п(р)одать

я бы уточнил, не столько его, сколько — себя, свои услуги не умеют продать. не умеют убедить — «видите какие мы крутые! нам можно доверить!»

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

Відповісти

Підтримати

Valentin Serduk

Serguei Tarassov 29.07.2014 16:59

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

Відповісти

Підтримати

undefined pointer 29.07.2014 17:04

Это специфика проектного софтостроения

или того что описано в книге
Дефрагментация мозга. Софтостроение изнутри
Автор: Сергей Тарасов

там, ИМХО, неряшливо многое написано, а многое из категории «старого пердунства», но от на что там постоянно указывается что проектирование то и — ушло из софтостроения.

а софтостроение стало напоминать создание анимационных фильмов, по процессу. не мое, я с автором этого тезиса даже поспорил. но, через полгодика — согласился что он прав см vit-r ЖЖ рубрика it

Відповісти

Підтримати

Serguei Tarassov

Ще 10 коментарів

Serguei Tarassov 29.07.2014 17:10

Рецензия Виталия: vit-r.livejournal.com/753845.html
Готова новая книга «Работа с СУБД для программиста. Базы данных изнутри», позволяющая, при вдумчивом чтении, избежать скоропостижных переходов на NoSQL.

Відповісти

Підтримати

undefined pointer

undefined pointer 29.07.2014 17:16

ну, я то и не являюсь фанатом NoSQL. и приводил ссылки на статьи Зубинского, редкого в русскоязычном пространстве «itшного журналиста». в его блоге на КО посмотрите, как он эту революцию в кавычки берет :)

Відповісти

Підтримати

Serguei Tarassov

Serguei Tarassov 29.07.2014 17:20

Надеюсь, его кто-то услышит. Большинство будут набивать шишки о слабоструктурированные модели данных, не зная об их существовании.

Відповісти

Підтримати

undefined pointer

undefined pointer 29.07.2014 17:31

ой, а вы часом не есть сам автор? тогда поясню что «старое пердунство» употребляю и к себе :) Мне понравилось у Голубицкого пару лет тому — «старым пердуном я стал лет в 35». ну и он метко описал это качественное изменение :)
молодежь просто многое в книге так и будет воспринимать, проверено на себе :)

Відповісти

Підтримати

Serguei Tarassov

Serguei Tarassov 29.07.2014 17:38

Во Франции более распространен другой термин, «vieux con», который в зависимости от степени вменяемости можно переводить, как «старый *удак», подставляя вместо звездочки нужную букву. Разница лишь в пороге, +10 лет примерно по сравнению с РФ. Ну, а процесс трансформации из молодых парней в старые чудаки описан в послесловии книжки :)

Відповісти

Підтримати

undefined pointer

undefined pointer 29.07.2014 17:54

еще не дочитал :) в метро читаю, день Дефрагментацию, день «Белую одиссею» Ильина
в целом — согласен, особенно с вопиющими фактами, и как раз рецензия vit-r сподвигла на прочтение.

про ORMы — один случай помнится — как-то в одном проекте стала система как-то мееедленно работать, по локальной сети. причем все по локалке стало тупить, а не только она. админов кляли все за это.
неугасающие лампочки хаба меня смутили, и возьми да проверь дневной внутренний трафик. потому что непонятно было, кто в сети то так грузит.
оказалось при БД размерчиком с полгига, накручивало по 15-20 гиг.
пришлось рыться в коде.
а там — мало того что о те самые выборки гирлянд объектов ради одного поля, кто-то еще самопальный кэш вклепал — он эти гирлянды наперед вычитывал, многопоточность, хуле простаивать, вдруг пригодятся!

итого, при еще добавленных тройке машин — не просто сервер БД лег, а вся локалка легла.

«перекрестился» что не мне это дело переписывать :)

Відповісти

Підтримати

Serguei Tarassov

Serguei Tarassov 29.07.2014 18:14

Это много хуже допотопных файл-серверных систем, крутивших в локальной 10 Мбитной сети на 150 пользователей файлы с сотнями мегабайт данных, сервер пентиум-1 200 МГц, память 8-16 МБайт (везде М, а не Г, т.е. железо в 1000 раз слабее).
Потому что ОРП часто используют так же, как файлы в клиппере.
Навигационная обработка, добро пожаловать в 1980-е...

Відповісти

Підтримати

undefined pointer

undefined pointer 29.07.2014 18:22

Это много хуже допотопных файл-серверных систем

я знаю :) как-то видел систему написанную на plain C, на границе 90ых, под arcnet. БД ребята изобрели свою, как и описание экранных форм чтобы просто — генерировались. и оказалось — чтобы десятки терминалов в такой сети обслуживать — не надо и большой науки, просто — аккуратность, и «ничего лишнего». причем она была еще — и распределенной :)

лет с 5 тому только заменили. жила себе, просто состарились или разъехались ее авторы, чтобы добавлять функционал. а сишника — поди найди.

Навигационная обработка, добро пожаловать в 1980-е...

именно.
спрашивается — какого? я на MUMPS отак бегал, теперь тоже самое — только по объектам. а где обещанный SQL?
причем на MUMPS я бегал очень «точно», никаких лишних чтений вместо меня он не делал. а тут — дай поле — на тебе десяток объектов.

вобщем, «старые» мы с вами «пердуны» :)

Відповісти

Підтримати

Serguei Tarassov

Serguei Tarassov 29.07.2014 18:37

Иерархическая модель — по графу особо не побегаешь :)
Успехов вам в софтостроении, как и автору темы!

Відповісти

Підтримати

undefined pointer

Serguei Tarassov 04.08.2014 13:26

P.S. Анонс книги «СУБД для программиста. Базы данных изнутри» и опрос общественного мнения. Рапространение приветствуется.
arbinada.com/main/node/1372

Відповісти

Підтримати

undefined pointer

Me Redo 29.07.2014 16:05

Не могу не заметить ограниченность автора. Поймите наконец: заказчику абсолютно по барабану какая технология эффективней и какие плюшки есть в каких-то языках. Ровно также ему не интересно насколько чист ваш код с точки зрения профессионализма. Главная задача — это уверенность в том, что проект заработает.
Какая разница в каких футболках (Java или Groovy) будут сантехники (программисты), если результатом должен быть работающий кран? Популярность стоит за джавой. Специалистов в этой области больше. А значит меньше рисков. Больше готовых проектов, которые подтверждают репутацию джавы.
Вот что важно для заказчика. Перестаньте идеализировать технологию. Программисты — это слесари 21-го века. А вы когда слесаря выбираете, вы сильно обращаете внимание на его инструменты? Лично я, выбираю, по резюме слесаря и по отзывам о нем, пусть хоть он работает молотком и зубилом.

Відповісти

Підтримати

Yakov Fain Managing Director and Partner в Farata Systems 29.07.2014 14:13

Я вот тоже разочаровался в крестовой отвертке — не все шурупы откручивает. Перейду на плоскую.

Відповісти

Підтримати

undefined pointer 29.07.2014 17:07

эх Будам, развернули бы мысль, с вашим опытом — любое замечание было бы интересным и ценным :) тем более как вы сами сказали в одном из подкастов — «программирование поднадоело, это для молодых, а мне уже интересней реализация проекта в целом» (по памяти)

Відповісти

Підтримати

Ще 4 коментарі

Yakov Fain Managing Director and Partner в Farata Systems 29.07.2014 17:21

А что еще разворачивать? Языки программирования — это инструменты в ремонтном наборе ремесленника под названием Программист. Чем больше у тебя инструментов, которыми ты умеешь пользоваться, тем лучше.

А говорить, что PHP — это хорошо, потому, что на нем можно слепить веб страничку за два дня — признак незрелости. Кстати, автор подзабыл, что Java — это не только ценный мех, но и супер мощная JVM, на которой будет выполняться откомпилированная cool Scala.

А восьмая Java — просто песня. Я недавно написал пару блогов о lambda and closures. Посмотрите здесь: yakovfain.com. Кому-то скучно? Мне нет.

Відповісти

Підтримати

undefined pointer

Mykola Kosianchuk Senior Android developer 30.07.2014 10:19

да что говорить...человек только 4 проекта провел на Джава. Выводы делать рано. Под каждую задачу — хорош свой «инструмент» в лице ЯП.

Відповісти

Підтримати

Yurii V 30.07.2014 12:29

Я разочаровался в Java как в языке

Автор нічого не дає взамін. Що заважає йому взяти дві книги — специфікація віртуальної машини та мови і розробити свою мову, яка працювала під ВМ? Створити щось нове слабо?

Відповісти

Підтримати

Mykola Kosianchuk

Gabriel Angelos 30.07.2014 21:20

Да, Николай, мне до вас далеко конечно. Как успехи у вашей группы, что успели освоить за 2 месяца?

Відповісти

Підтримати

Mykola Kosianchuk

Yuriy Ryndin 29.07.2014 13:10

python? не?

Відповісти

Підтримати

mobile mobile 29.07.2014 00:43

я закончил тренинг по java core и начал смотреть что бы мне такого еще выучить что бы приблизится к уровню junior. Налево посмотрел — какие то java EE , направо — android, посредине Spring, слева Hibernate. За что браться — нефига не понятно. Пошел посмотрел вакансии на джине — для новичков ничего нету. Посмотрел PHP, Perl, Ruby, Python. На PHP требуют знаний фреймворков — то зенд, то йойо, то симфония — короче дофига учить. На питоне — можна приходить с начальными знаниями но позиций мало, на руби — тоже берут после пары учебных проектов позиций побольше. Вот и выходит — вход на рынок джавы требует дофига подготовки, тогда как на другие языки берут прямо после курсов. Может ну его нафиг эту джаву ?

Відповісти

Підтримати

Владислав Галий Android Developer 29.07.2014 10:51

Я близок ко всему сказанному. Разве что с поправкой для PHP, туда берут и без знания фреймов, причем очередь работодателей стоит, о качестве, конечно, сказать не возьмусь.
Но раз уж java core закончил, чего сдаваться-то на полпути. Я свернул направо, посмотрим чё там будет:)

Відповісти

Підтримати

anonymous 28.07.2014 18:34

Меня реально бесит JPA/Hibernate, есть так много вещей которые можно сделать на SQL гораздо проще и все это будет работать быстро и что самое важное как написано так и работает, а не генерирует 16 outer join’ов. Но все программисты привыкли к ORM’ам и не хотят с них слазить.

P.s. Рекомендую mybatis он простой, эффективный, легковесный.

Відповісти

Підтримати

Gabriel Angelos 28.07.2014 22:55

Может стоит уже завязать с Agile и начать хоть немного проектировать архитектуру, анализировать слабые места и проверять адекватность требований на моделях? Я понимаю что для заказчика и для аутсорсера Agile — манна небесная. Аутсорсеру — бабло, заказчику — ~~лапшу на уши~~ по фиче каждые 2 недели. По факту это индусский фекало-конвейер.

Реляционная модель хранения данных нежизнеспособна при росте/адаптации системы, получается эдакий Франкенштейн и каждая фича — пришитая к оживленному мертвому телу конечность.

Hibernate — хороший инструмент, свой «велосипед» имеет смысл писать, если:
— ДЕЙСТВИТЕЛЬНО есть требования к очень высокой производительности
— Hibernate является узким местом системы, а не скажем бизнес-логика, открывающая/закрывающая вручную транзакцию 100-200 раз для построения каждой сущности.

Відповісти

Підтримати

Ще 13 коментарів

Bogdan Shyiak SE or Dev 28.07.2014 23:16

Реляционная модель хранения данных нежизнеспособна при росте/адаптации системы

Выбирайте любое:
1) лол просто лол
2) А мужики то и не знают
3) Дашотыгавариш?!

Відповісти

Підтримати

Gabriel Angelos

Gabriel Angelos 28.07.2014 23:37

4) Если франкенштейн (реляционная модель) передвигается/как-то пыхтит, то он — жив и все хорошо?

Відповісти

Підтримати

Valentin Serduk Technology Manager 01.08.2014 11:53

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

Відповісти

Підтримати

Gabriel Angelos

Tim Tretyak ASM, TS Consultant в Hewlett Packard Enterprise 04.08.2014 14:12

Интересно — а есть хоть одна АБС на нереляционке в природе?
Или ERP?
Имею ввиду реально внедренные и работающие у клиентов.

Відповісти

Підтримати

Valentin Serduk

Valentin Serduk Technology Manager 04.08.2014 14:19

нет и очень сомневаюсь в возможности построения такой АБС. оно и не логично, потому что требуется консистентность, строгая типизация(регламентация если мы о субд) и прочие ништяки. там вообще нельзя записи терять, никак. лучше медленнее работать. логичнее выглядит работа с NoSQL с сохранением из нее критичных данных в SQL. сейчас нечто подобное построили, проблемы есть, но перспективы и производительность радуют

Відповісти

Підтримати

Tim Tretyak ASM, TS Consultant в Hewlett Packard Enterprise 04.08.2014 14:23

NoSQL с сохранением из нее критичных данных в SQL.

Кстати да — идея интересная. Спасибо!
Энтерпрайз традиционно направление аналитики заливает деньгами (Vertica, HANA etc.), а идея такого «гибрида» выглядит изящно. Классно если взлетит!

Відповісти

Підтримати

Valentin Serduk

Valentin Serduk Technology Manager 04.08.2014 14:27

да это стандартное в общем-то решение. работа с распределенным NoSQL с записью всего что нельзя потерять в SQL. Для банков особенно красиво т.к. все что надо писать это исключительно транзакции(денежные), остальное если и потеряется то ничего смертельного не произойдет.

Відповісти

Підтримати

Tim Tretyak ASM, TS Consultant в Hewlett Packard Enterprise 04.08.2014 15:59

да это стандартное в общем-то решение

Скорее концепция.
В существующих АБС я пока про реализацию не слышал. Хотя тут у меня мало опыта, возможно уже появились.

Відповісти

Підтримати

Valentin Serduk

undefined pointer 04.08.2014 14:57

Или ERP?

1. данные в бизнес системах обычно — однотипные по характеристикам, и ключевые, важные для бизнеса, характеристики данных количественные.
2.а изменение количественных характеристик обычно требуется атомарно — многих.
2.б причем при старте атомарной операции часто невозможно предсказать ее успешное завершение, согласно бизнес-правилам.
3. эти атомарные операции частенько конкурируют за общие данные. а порядок изменения данных в бизнесе — обычно очень важен. на оси времени.

какие БД лучше всего оперируют с операциями над количественными данными в жирных транзакциях, с произвольным проверками, с конкурентным доступом к данным?

Відповісти

Підтримати

Tim Tretyak ASM, TS Consultant в Hewlett Packard Enterprise 04.08.2014 16:12

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

Хмм, нет.
Вся первичка, склады, кадры, финансы — наборы документов со строгими хар-ками и индивидуальным прохождением.
Требования к целостности превалируют над всеми остальными (абсолютно критично), требования к доступности также высоки для выполнения операционной деятельности.
.
А вот построенная на них аналитика уже обладает перечисленными вами хар-ками. И в этом конфликт подходов и проявляется.
В прошлом данные просто сгружались в ОЛАПы и датаварехаузы, где начинали жить собственной жизнью по отношениею к оперативным. Но датаварехаузы быстро дохли от нарастания энтропии, которую сервероцентричные реляционки жутко не любят.
.
Гибридные системы видятся годным путем развития имхо.
От реляционок явно в следующие лет 10 отказываться рано.

Відповісти

Підтримати

undefined pointer

undefined pointer 04.08.2014 17:04

Вся первичка, склады, кадры, финансы

кол-во денег, кол-во штук, кол-во ставок, кол-во отработанных часов

Требования к целостности превалируют над всеми остальными

потеря информации «на сколько денех продано» критичней потери «чего продано»

А вот построенная на них аналитика

и опять — кол-во. причем, если в первичке была инфа о «названиях пылесосов», то в аналитике свернуто по «бытовая техника», и опять — кол-во денех, кол-во штук.

Гибридные системы видятся годным путем развития имхо.

не очень понятно — на кой.

если брать системы документооборота, то она требуется для другого вида документов. в которых нет этих кол-во. а в общем случае — фиксация этапов бизнес-процессов или еще какого workflow. то бишь — то за что отвечают отдельные BPM сервера(или их совмещение с архивом в виде PLM систем). бизнес-транзакция тогда состоит из двух серверных — «отмечаем изменения состояния по карте процесса» «изменяем кол-во» — откат если одна из операций не прошла.

какой выигрыш от применения связки NoSQl и SQL? не вижу.

Відповісти

Підтримати

Sergii Maliarov Software Developer at AIMMS 29.07.2014 12:10

Реляционная модель хранения данных нежизнеспособна при росте/адаптации системы, получается эдакий Франкенштейн и каждая фича — пришитая к оживленному мертвому телу конечность.

А не наоборот? На маленьких проектах хорошо, когда нет SQL, но с ростом требований типа «хочу показывать связанные сущности тут и там» оказывается, что хорошо, когда данные реляционные.

Відповісти

Підтримати

Gabriel Angelos

Andriy Mishak IT Software Engineer (AD) в UBS 29.07.2014 12:29

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

Скажите, а Вы когда-нибудь начинали проектировать архитектуру в отсутствии требований по проекту от заказчика? :)

Відповісти

Підтримати

Gabriel Angelos

Нестор Иванович 28.07.2014 04:23

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

Відповісти

Підтримати

undefined pointer 28.07.2014 14:57

это да, функциональщики, а особенно хаскелисты понабежавшие в скалу за зарплатами мира JVM — размазывают по стенке легко и непринужденно.

Відповісти

Підтримати

Нестор Иванович

Ще 1 коментар

Нестор Иванович 28.07.2014 16:04

да нет просто там как в академической среде — быть мдаком почетно

Відповісти

Підтримати

undefined pointer

Maks Rybalchenko 28.07.2014 01:19

Это что выходит, я зря начал java изучать? :D

Відповісти

Підтримати

undefined pointer 28.07.2014 14:58

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

Відповісти

Підтримати

Maks Rybalchenko

Viktor Sovietov Founder in theplatform.technology and smarter.trading в smarter.trading 27.07.2014 13:01

Это еще что, вот когда риалтайм, низкие латентности и оффхип — вот тогда яд.

Відповісти

Підтримати

foror 27.07.2014 09:39

— grails, groovy это не java, не проще тогда сразу разрабатывать на ruby on rails, а не на его жалком поделии в виде grails? Всё правильно, что вам не дали использовать groovy в java проекте.

— nosql база данных, зависит конечно от проекта, но скорее всего вас просто зазомбировали идеологи nosql. Так что есть подозрение, что заказчик и тут прав выбрав свой SQL сервер.

Почему при разработке на Java всегда тяжело и всегда испытываешь страдание

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

Почему Java жрет так много памяти?

Другие жрут не меньше и даже больше, сложные проекты на ruby on rails, например discourse жрут гораздо больше. Scala жрёт дохрена, не меньше, чем java, даже больше. Тем не менее, я без проблем запускаю java веб-проекты на 512Mb, просто использую легкие технологии jetty и tapestry 5.

Почему сам язык настолько беден и неуклюж? Почему работы с датами/потоками/коллекциями вызывают недоумение и неудобство. Поэтому на каждый чих — dependency, получаем на выходе гигантский артефакт/-ы и постоянные конфликты транзитивных зависимостей

Может вы просто не умеете их готовить?

Я разочаровался в Java как в языке так и в диаспоре/проектах под нее, думаю плотно переключаться на Scala и расти под нее.

Мдя, а scala, значит память не жрёт, веб-фреймворки на ней прекрасные, особенно понравился play, который выжрал 500 метров оперативки на холодном старте hello world... С dependency, там проблем нет и т.д?

В общем, вывод, что у вас просто небольшой опыт, либо просто работаете с говнопроектами, сделанные индусами. Я тоже с таким сталкивался, опыт придёт, а работу просто нужно поменять :)

Відповісти

Підтримати

undefined pointer 27.07.2014 10:08

tapestry 5.

да, для джава мира удивительно непривычный фреймворк.

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

То, что нет, инструментов под веб,

"
означает что есть другие инструменты :)

конечно, на tapestry 5 есть немало проектов, и как на нем правильно готовить показывают ребята из Atos Worldline. но... может потом как-нибудь напишу о нем.

grails, groovy это не java

да, потому что овса не требуют.

у меня знакомый, по реалу, сейчас в проекте на grails. Ваяют систему для финансистов. кредиты, проценты на проценты, вобщем — навороченная бизнес-логика, вся из исключений «из правил», и навороченный же UI. Так как до этого он и не слышал о нем, спросил, через пару месяцев, и как тебе уже, как практику. Ответ был — лучше инструмента в джава в мире пока не встречал.

очень классный в инженерном плане

весь топ-10 на Tiobe — это классные инструменты в инженерном плане

либо просто работаете с говнопроектами

тоже самое можно сказать о любом популярном инструменте.
чем популярней — тем больше на нем говнопроектов.

сколько народу бренькает на гитаре?
а вот на арфе — как-то не очень.
арфа хорошая, а гитара плохая? или наоборот, гитара для болванов а арфа для элиты?

Відповісти

Підтримати

Ще 6 коментарів

foror 27.07.2014 10:50

весь топ-10 на Tiobe — это классные инструменты в инженерном плане

И джава там, обычно на первом, втором месте уже как кучу лет.

означает что есть другие инструменты

Какие? Grails? Так это поделие, клон Ruby on Rails, спрашивается зачем использовать поделие, когда доступен оригинал?

Відповісти

Підтримати

undefined pointer

undefined pointer 27.07.2014 11:01

И джава там, обычно на первом, втором месте уже как кучу лет.

и С.

я к тому помянул что говорить о том что находится в топе Тiobe «инженерный» — это тавтология, масло маслянное

Так это поделие, клон Ruby on Rails, спрашивается зачем использовать поделие, когда доступен оригинал?

отвечается, словам Эккеля:
в мире JVM Java со временем может стать ассемблером, если уже не стала.

поясняется, для фанатиков

1. в случае необходимости, часть модулей можно переписать на Java. в Ruby on Rails придется на C дописывать расширения интерпретатора Ruby
2. в мире JVM тьма инструментов которые можно будет использовать в проекте на Grails

так что с точки зрения здравого инженерного мышления — Grails хороший выбор.

В мире джава давно встретил самокритичную шутку:
— вот это, можно написать?
— это? не, низя, нет такой библиотеки

потому что:
на Java сложно, долго писать.

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 27.07.2014 11:23

В мире джава давно встретил самокритичную шутку:
— вот это, можно написать?
— это? не, низя, нет такой библиотеки

В джава нет библиотеки для чего-то? Танунах! :)

Відповісти

Підтримати

undefined pointer

undefined pointer 27.07.2014 13:04

В джава нет библиотеки для чего-то? Танунах! :)

в джава-проектах запросто можно использовать библиотеку кроме 10ка православных?
освоение библиотеки, а потом чтение когда использующего эту библиотеку, неосвоившим ее — тоже ну никаких проблем?

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

Відповісти

Підтримати

foror 27.07.2014 12:01

Не проще сделать вот так en.wikipedia.org/...y#Ruby_on_Rails ?

С чего это долго и сложно писать? Там что, какие-то иероглифы или синтаксис кардинально отличим от php, c, c++, javascript? Думаю этот миф появился из-за высокого порога вхождения и из-за преобладания JavaEE стека. И порождают такие мифы авторы как и автор данного топика. Но профессионализм подобных авторов можно проследить по нижележащим постам...

Відповісти

Підтримати

undefined pointer

foror 27.07.2014 12:05

Достаточно вот такого перла «Вот смотрите, чем больше умеет язык, тем меньше сторонних либ и приблуд надо подключать. Меньше либ, меньше памяти, меньше памяти, меньше (в среднем) нагрузка на CPU.», а потом начинается, что «на java сложно и долго писать»

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

Відповісти

Підтримати

reality_hacker 27.07.2014 00:16

Еще забавно что как альтернативу автор предлагает недофреймворк на который все забили с тем же хибернейтом и спрингом внутри, написанный на тормозном языке с динамической типизацией. Как это должно решать проблему 128ГБ памяти и 8 процов?

Відповісти

Підтримати

Gabriel Angelos 27.07.2014 00:42

Я изложил свое виденье разработки на Java за свои честные 3,5 года опыта. Я вижу в Scala будущее для себя в профессиональном плане. Меня интересует исключительно профессиональный рост, а не уборка фекалий за кем-то другим за любые деньги.

Как это должно решать проблему 128ГБ памяти и 8 процов?

Писал раза 4 уже в разной форме. Вот смотрите, чем больше умеет язык, тем меньше сторонних либ и приблуд надо подключать. Меньше либ, меньше памяти, меньше памяти, меньше (в среднем) нагрузка на CPU.

Відповісти

Підтримати

Ще 3 коментарі

Artyom Krivokrisenko 27.07.2014 00:53

facepalm

Відповісти

Підтримати

Gabriel Angelos

Bogdan Shyiak SE or Dev 27.07.2014 00:54

Вот смотрите, чем больше умеет язык, тем меньше сторонних либ и приблуд надо подключать. Меньше либ, меньше памяти, меньше памяти, меньше (в среднем) нагрузка на CPU.

От именно поэтому я и говорил что «лямбды — это зло». :)
1) «Либы» (классы) занимают пермген (метаспейс). Тут речь идет про мегабайты (даже не сотни мегамайт)
2) Груви/Скала не так уж и много умеют на уровне языка/компилятора. Большая часть их фич это синтаксический сахар который уходит в те же либы. Стандартная библиотека загружается в память точно так же как и сторонняя.
Ну и вам сказали что магический Грейлс — это сахар поверх спринга и хибера, при том те кто «остался на джаве» имеют возможность выбирать более легковесные инструменты.

Відповісти

Підтримати

Gabriel Angelos

reality_hacker 27.07.2014 01:04

Я изложил свое виденье разработки на Java за свои честные 3,5 года опыта. Я вижу в Scala будущее для себя в профессиональном плане. Меня интересует исключительно профессиональный рост, а не уборка фекалий за кем-то другим за любые деньги.

Ухаха, а код на скале исключительно фекалий содержать не может?

Писал раза 4 уже в разной форме. Вот смотрите, чем больше умеет язык, тем меньше сторонних либ и приблуд надо подключать. Меньше либ, меньше памяти, меньше памяти, меньше (в среднем) нагрузка на CPU.

А с чего ты взял что в грельсах депенденсей меньше чем на абстрактном спринг проекте?

Відповісти

Підтримати

Gabriel Angelos

undefined pointer 26.07.2014 20:34

никого не хочу обидеть, тем более что сам в джава мире, но как-то часто, не только на доу, разговоры о джава превращаются в ситуацию (мое по мотивам фразы Генри Форда):

После рассказа конюху о преимуществах автомобиля, конюх обходит его, думает, и говорит:
— да, я вижу что лошадей прицепить не к чему. вижу что и срать не будет. Но овес то чем оно жует?

Яркий и частый пример:
А как же без ORM сложную дата модель обслуживать???

То есть — следствие перепутано с причиной:
вначале наворотим сложную дата модель, разрисуем UML по рецептуре DDD, а потом покажем что без овса то — никак не возможно.

С этим примером есть и другой казус, похлеще:
Детальная проработка предметной области подразумевает — проектирование.
которое, встречал, может занимать до 70-80% времени.
А какое оно при радостном — а у нас аджайло-скрам по оригинальной рецептуре!
проектирование то?

в итоге, дата модель не просто сложна, в ней навалено конями, на каждой итерации стоооолько, что жевать овес уже приходится ваятелями, а не этой штукой, под названием ORM

Відповісти

Підтримати

Oksana Chuiko Software Engineer в Pure Storage 26.07.2014 21:18

а какая разница на чем эти модели воротить? Т.е. на том же PHP можно сделать то же самое со скарамами\аджайлами, но просто и несложно?

Детальная проработка предметной области подразумевает — проектирование.
которое, встречал, может занимать до 70-80% времени.

У меня есть знакомый, который пытается организовать аутсорсинговую компанию. От клиентов он требует детальной проработки задачи. Какие либо изменения в проект (к которым мы так привыкли с аджайлом) вносятся только в виде ооочень большого одолжения. К нему никто не хочет идти. Мало кто изначально четко знает что ему нужно.
Можно хоть 300 раз спроектировать гениальнейшую архитектуру, но потом сроки с задачи так или иначе сделают из нее монстра. Я не очень спец в других технологиях, но большие проекты на джаве и питоне, которые я видела — все этим страдали.

Відповісти

Підтримати

undefined pointer

Ще 2 коментарі

undefined pointer 26.07.2014 21:33

а какая разница на чем эти модели воротить?

вопрос не в чем — а в почему

Т.е. на том же PHP можно сделать то же самое со скарамами\аджайлами, но просто и несложно?

недавно на тусовке phpистов мне ответил один об одном фреймворке — это не php way

Но вы задаете все тот же вопрос:
— а чем оно овес то жует?

От клиентов он требует детальной проработки задачи

а самим себе программы писать он от клиентов не требует?

вы посоветуйте ему погуглить на тему «Сбор и управление требованиями».

Мало кто изначально четко знает что ему нужно.

Это откровение я встречал в стольких канонических учебниках по программированию, с разъяснением что они, клиенты совершенно и не обязаны знать, что им нужно, что не знаю — почему оно откровение для многих программистов и удивляет?

Можно хоть 300 раз спроектировать гениальнейшую архитектуру

как сказал Фаулер:
«архитектура — это застывший дизайн».
сказал он в контексте, который мне напомнил уличные туалеты на Севере, возле военных сооружений —
полметра до мерзлоты яма, пол, метр до дырки, и растет сталагмит. Когда высота его начинает подходить к дырке — посылается джун("дух") с ломом. ну, или провинившийся.
на улице −30 обычное дело. Крепка архитектура получается!

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

то бишь вопрос — а нужно то, проектировать архитектуру?
тем более когда ее — мало кто проектирует, а оно как-то само получается.

Відповісти

Підтримати

Pavel Kruchina CTO 26.07.2014 21:54

Стадия 1. Делаем абы как (собственно как делать по другому не знаем). Получается плохо.
Стадия 2. Решаем что неплохо было бы распланировать работу. Все жестко планируем — получается плохо.

Теперь уже возможны варианты. Либо «ну его нафиг» и goto 1, либо «нужно лучше планировать» и goto 2, либо

Стадия 3. Понимаем что есть вещи которые нужно планировать, и есть вещи которые планировать бессмысленно.

Відповісти

Підтримати

undefined pointer

Anatoli Koutsevol 27.07.2014 01:57

А как же без ORM сложную дата модель обслуживать

Как-то потратил пару месяцев, удаляя Hibernate из средних размеров проекта. Все как-то работало пока не пришлось снимать образы современных баз сверхбольшого размера. Сохраняя посредством ORM сверхбольшие структуры, приходится иметь дело с пропорциональным расходом памяти, и всякие ухищрения типа stateless sessions в случае, когда в ходе записи необходимо чего-то перечесть, не слишком помогают. Похоже, надо сильно извратиться, чтоб записать с Hibernate сложную структуру неограниченного объема, располагая ограниченным объемом памяти, но и тогда такое извращение будет работать неоправданно долго.

Відповісти

Підтримати

undefined pointer

Ще 3 коментарі

undefined pointer 27.07.2014 08:50

вот вот.

конюхи обычно и холиваров Rich vs Anemic не читали.
вот и получается — намыслили в Rich стайл, держа в уме Hibernate, а потом удивленно спрашивают: А как же без Hibernate эту жирную модель в базе держать???

действительно, если поставить вначале левую ногу на ступеньку, как же поставить раньше ее правую ногу на эту ступеньку?

ессно надо уточнить (а то набегут с банальностями)
1. серебряной пули не существует
2. сложные проблемы вряд ли имеют простые решения

у технологии, подхода X поэтому мы всегда найдем список действительных недостатков.

Відповісти

Підтримати

Anatoli Koutsevol

Gremlin 28.07.2014 22:49

Как-то потратил пару месяцев, удаляя Hibernate

выколупывание Хибера — проверенный паттерн при оптимизации тормозной аппликухи.

Відповісти

Підтримати

Anatoli Koutsevol

Anatoli Koutsevol 29.07.2014 03:47

Хоть это и проходит по ведомству оптимизации, нас больше заботила scalability. ORM неплохо справляется с ростом сложности сохраняемой модели. Хуже, когда рост сложности сопровождается существенным увеличением объема данных. В принципе, клиент с пониманием относится к увеличению времени обработки возросших объемов данных, но его никак не устраивает out of memory exception в качестве конечного результата этого процесса.

Відповісти

Підтримати

Oleksii Beloborodov Android dev. 26.07.2014 19:40

А мені — подобається :)

Відповісти

Підтримати

Denys Ievstratenko Senior Java Developer 26.07.2014 15:18

1) Учтите, что уже есть Java 8;
2) Сам смотрел в сторону Scala. Очень интересный, современный язык, но есть ли необходимые фреймворки для создания полноценного enterprise приложения? Что если я должен использовать реляционную базу, то есть ли какой-либо стоящий аналог Hibernate? Есть ли аналоги Spring (не только DI, но и MVC, Security, AOP и т.д.).
3) По поводу NoSQL баз. Интересовался когда-то MongoDB. Опять же очень удобно и интересно, но там вообще нет транзакций и join-ов. Это критично, вообще-то, если я не могу откатиться или выбрать данные за один запрос. Есть ли другие NoSQL базы, в которых эта проблема решена?

P.S. вопросы совсем не риторические, правда интересно

Відповісти

Підтримати

undefined pointer 26.07.2014 15:30

Scala не взлетит, как массовый ЯП.

но я о п2 — «есть ли необходимые фреймворки»

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

напр этот пост я написал без всяких фреймворков. почему?

по п3 я тоже не разделяю восторгов о «серебрянной пуле»

нравится:
Зубинский
NoSQL. И никаких «революций»
NoSQL. Column-Oriented

Відповісти

Підтримати

Denys Ievstratenko

Ще 18 коментарів

Denys Ievstratenko Senior Java Developer 26.07.2014 15:37

чем более богат ЯП, для реализации требования по месту, тем меньше есть нужда в фреймворках

Не совсем ясно. DI и ORM должны быть частью ЯП по-вашему?

Відповісти

Підтримати

undefined pointer

undefined pointer 26.07.2014 15:52

зачем, скажем в Haskell — DI?
т.е. — а удобный костыль — обязателен ли к использованию здоровым?

ORM — а оно — откуда, почему взялось? Критику ORM как подхода приводить не буду, ее очень много уже существует. Например есть такая, практическая: «ORM создан для тех кто не в состоянии асилить декларативный SQL» конечно это утрировано, и преимущества использования ORM есть. Но вот в очередной раз пободавшись с хибером, чтобы заставить его элементарной в SQL операции... понимаю что этой боданины не замечают те кто SQL не знает даже на моем, весьма посредственном уровне. А такой посредственный мой уровень еще и потому что — а не даст никто использовать SQL. Запрещено!
SQL при использовании реляционных баз данных — запрещен!
о как на планете Java.
Если есть здоровые ноги — ХОДИТЬ ими запрещено! Только на костылях!
а если богат, только погрузчиком в кресло кабриолета, даже костыли запрещены.

Как и Groovy, а уж про Grails...

Скажу еще что даже этот подход, ORM, можно очень по разному реализовывать.
В зависимости от свойств ЯП.

Відповісти

Підтримати

Denys Ievstratenko

Denys Ievstratenko Senior Java Developer 26.07.2014 18:19

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

Відповісти

Підтримати

undefined pointer

undefined pointer 26.07.2014 18:45

критики от программистов на других ЯП — «что делает Java с мозгом программиста» — тоже хоть отбавляй.

не вижу смысла ее повторять, но как вижу по ответу, она тоже вполне адекватна, как и в адрес ORM

Відповісти

Підтримати

Denys Ievstratenko

Oksana Chuiko Software Engineer в Pure Storage 26.07.2014 21:23

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

Відповісти

Підтримати

Denys Ievstratenko

Дмитро 26.07.2014 22:14

Вопрос удобства рефакторинга в реально сложной доменной модели, должен беспокоить куда больше, чем быстрый и прозрачный запрос. Сегодняшний этап развития ORM в связке с языком со строгой системой типов вроде java и возможностями ООП будет практически всегда предпочтительней для реализации сложно бизнес логики, чем процедурный sql по многим причинам.

Відповісти

Підтримати

Tim Tretyak ASM, TS Consultant в Hewlett Packard Enterprise 28.07.2014 23:16

Вопрос удобства рефакторинга в реально сложной доменной модели

Но ведь доменная модель всегда будет как минимум такой же сложности, как лежащая под ней реляционная?
Основной плюс ОРМ — совместимость как с реляционными, так и нереляционными СУБД и большая экономия времени при переходе от первой ко второй.
Во всех остальных случаях ИМХО реляционный подход будет выигрывать.

Відповісти

Підтримати

Дмитро 29.07.2014 08:10

Но ведь доменная модель всегда будет как минимум такой же сложности, как лежащая под ней реляционная?

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

Вынесение доменной логики в SQL может решить ряд проблем использования ОРМ(которые чаще всего связаны именно с боками проектирования системы, доменной модели или неумелым использованием ОРМ), но это практически всегда будет сопровождатся потерей гибкости, ухудшением качества кода, ростом количества багов и времени требуемого для добавления новых фич.

Відповісти

Підтримати

Tim Tretyak ASM, TS Consultant в Hewlett Packard Enterprise 29.07.2014 19:26

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

Беда только в том, что при этом будет стремительно накапливаться энтропия и теряться управляемость. В тот момент, когда у программистов окончательно потеряется в голове представление о нижнем реляционном уровне — пойдут бока.
Думаю, что с нереляционными хранилищами будет в этом плане полегче, там тяжелее «наступить себе на хвост».

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

В этом плане SQL как раз очень прост и нагляден — там или сразу не работает, или работает правильно и проблемы возникают уже при многократном увеличении нагрузки.
Мощный SQL программист-DBA как правило избавляет всю команду от вышеописанных эффектов гарантировано при любой сложности модели.
Но т.к. у SQL есть нерешаемая на сегодня проблема «сервероцентричности» и уходящей в космос стоимости владения при значительных повышениях нагрузки, на этапах проектирования систем, когда еще неизвестно будет ли этот порог превышен (и такая вероятность не мала), безусловно стоит либо прокладывать ОРМ, либо сразу закладывать nosql решения.

Відповісти

Підтримати

Denys Ievstratenko Senior Java Developer 26.07.2014 22:17

может эти дяди не хотели учить что-то новое?

Відповісти

Підтримати

Gremlin 28.07.2014 22:51

дяди стареют и умирают, а SQL всё тот же.
ну почти))

Відповісти

Підтримати

Denys Ievstratenko

Gabriel Angelos 26.07.2014 22:23

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

Відповісти

Підтримати

reality_hacker 26.07.2014 22:51

А прикинь какой бы был ад если бы эти дядьки писали на похапэ?

Відповісти

Підтримати

Gabriel Angelos

Volodymyr Shynkliar 28.07.2014 13:58

Вони що, ці дяді, компілювали в себе локально і бінарники комітали ? O_0

Відповісти

Підтримати

Gabriel Angelos

Gabriel Angelos 28.07.2014 20:11

К сожалению нет, просто они отвечали за функционал = куски кода и не позволяли никому кроме себя эти куски править, а если кто-то просил рассказать что происходит там — посылали подальше. Некоторые делали «job-security» — одноуровневый пакет 200-300 классов без единого комментария и переменными типа «пыщ пыщ адин-адин».

Да, такое бывает, ведь senior-ы могут позволить себе практически всё.

Відповісти

Підтримати

Volodymyr Shynkliar

Volodymyr Shynkliar 30.07.2014 12:47

Жесть, просто жесть. (((
Добре що я не стикався з таким в ніжному віці.

Відповісти

Підтримати

Gabriel Angelos

Vasya Pupking 26.07.2014 19:21

если есть здоровые ноги, то накой машины да самолеты? Пешком, везде пешком...

Відповісти

Підтримати

undefined pointer

undefined pointer 26.07.2014 20:17

я же написал — если есть машины, то на машине, на машине, только на машине!

а на самолете вообще удобно нужду справлять, дырку прорезал — экономия на унитазах и канализации!

Відповісти

Підтримати

Виталий Мигов Senior Java/Scala Developer, Architect 30.07.2014 12:09

Scala может использоваться совместно с любым Java и Java EE фреймворком. Вообще говоря из Scala можно использовать любой Java класс.
НО, как правило желание использовать Spring/Hibernate и пр.. в процессе разработки на Scala очень быстро улетучивается в силу того, что Scala ( точнее Typesafe stack ) предлагает другое виденение архитекутры. А если сюда добавить еще и Akka persistent actors + CQRS/Event sourcing то Hibernate уже начинает выглядеть как нечто весьма допотопное ( как паровой двигатель по сравнению с электромотором ).

Відповісти

Підтримати

Denys Ievstratenko

Ще 11 коментарів

Denys Ievstratenko Senior Java Developer 30.07.2014 22:08

так и не понял, как мапить в базу данные

Відповісти

Підтримати

Виталий Мигов

Java Adept 30.07.2014 23:17

Squeryl

Відповісти

Підтримати

Denys Ievstratenko

reality_hacker 31.07.2014 01:17

У них же каждые полгода мейнстримный ОРМ меняется, сейчас вроде слик на этом месте.

Відповісти

Підтримати

Gabriel Angelos 31.07.2014 22:01

И что в этом плохого? Это гораздо лучше чем тянуть 100500 deprecated г*вно методов как в Date или Thread, которые использовать как бы низзя, но они есть, чтобы не сломать фекальный велосипед 1997-го года. Хочешь юзать deprecated — сиди на Java 1.1 — 1.3, ну я так считаю.

Відповісти

Підтримати

reality_hacker 31.07.2014 22:02

Ну вот пишешь ты клевый проект, у тебя 100500 юзеров, уже гигабайт кода, а потом вдруг оказывается что на твой фреймворк все забили, баги не фиксят, фреймворк морально устарел и фичами не обрастает. Все переписывать? И так каждые Н лет?

Відповісти

Підтримати

Gabriel Angelos

Gabriel Angelos 31.07.2014 22:08

Если вы тянете своего мамонта в новую версию, то будьте любезны соответствовать, переписывать не так уж много. Вдруг у вас там 2 млрд sleep-ов по всему коду?

Либо если все работает и все протестировано на Java 1.3 — не лезьте в него и не повышайте версию. Неоднократно видел 1.5 -> 1.7, 1.6->1.7, 1.6 ->1.8 и фсьо, проект уже не подымается. Так это просто базовая Java, а если опен-сорс фреймворки без обязательств, то там вообще поломалось — пеняй на себя.

Відповісти

Підтримати

reality_hacker 31.07.2014 22:11

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

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

Либо если все работает и все протестировано на Java 1.3 — не лезьте в него и не повышайте версию. Неоднократно видел 1.5 -> 1.7, 1.6->1.7, 1.6 ->1.8 и фсьо, проект уже не подымается. Так это просто базовая Java, а если опен-сорс фреймворки без обязательств, то там вообще поломалось — пеняй на себя.

1.3 уже давно не поддерживается, бизнесу таких рисков не нужно.
На джава 8 весь код должен работать, если там какие то хаки не использовались.

Відповісти

Підтримати

Gabriel Angelos

Bogdan Shyiak SE or Dev 31.07.2014 22:25

На джава 8 весь код должен работать, если там какие то хаки не использовались.

А фреймворки манипуляции с байткодом уже починили? Если нет, то тот же хибернейт не будет работать (не всегда, иногда, но больше и не надо).

Відповісти

Підтримати

reality_hacker 31.07.2014 22:35

Подробностей хотелось бы

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 31.07.2014 23:15

Подробностей хотелось бы

Подробностей не будет, так как «мопед не мой».
Пересказ в свободной форме:
Люди обновили джаву до 8-ки (где в апреле), начали юзать лямбды и тд, и хибер начал вести себя непредсказуемо — джава не находит классы, хотя на некоторые запросы с использованием данных классов отвечает.
Думаю это временно, но те фиксы которые будут (в джавассисте и тдт), потянут за собой не слабое обновление, которое подкинет проблем тем кто сидит не на самой последней версии всех фреймворков.
.
Но я спрашивал не с целью возразить, скорее узнать состояние дел.

Відповісти

Підтримати

reality_hacker 31.07.2014 23:43

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

Відповісти

Підтримати

undefined pointer 26.07.2014 14:25

Grails мог бы сэкономить 80% времени разработки, но нам его использовать не дадут,

80 не 80, но глядя на текущие проекты, на 50 — так точно, и по паре процентов экономия бы прибавлялась с каждой эволюционной итерацией.

Spring MVC + Sencha Ext JS — я не знаю какая технология была бы «дороже»... С++ на бэкэнде и написание собственного специализированного клиента для GUI на клиенте а-ля web-browser наверное.

но, 150% — о Grails и заикаться нет смысла.

Знакомые PHP-шники смеясь делают за 1-2 дня, в то время как нам требуется месяц.

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

Відповісти

Підтримати

Pavel Kruchina CTO 26.07.2014 14:33

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

Дожили :)

Відповісти

Підтримати

undefined pointer

Ще 1 коментар

undefined pointer 26.07.2014 14:43

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

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

Відповісти

Підтримати

Oleg Yakovlev Embedded C developer в GlobalLogic 26.07.2014 12:48

Джава — это всемирный заговор производителей вычислительной техники под руководством Оракла :-) Если бы не жаба, то где сейчас был бы рынок навороченных компов, которыми тут так любят меряться? )))))

Відповісти

Підтримати

NewType 26.07.2014 12:43

Некоторые из описанных проблем — вездесущи и не зависят от Java.
Legacy cr@p — это бич программистов, да.

Відповісти

Підтримати

reality_hacker 26.07.2014 21:38

Жабка кстати язык на котором очень приятно рефакторить из за мощных ИДЕ, так что это даже в плюсы джаве.

Відповісти

Підтримати

Ще 2 коментарі

Grez 27.07.2014 07:43

Ни одно ИДЕ никогда не сможет зарефакторить легаси креп.

Відповісти

Підтримати

reality_hacker 27.07.2014 09:59

Сама нет, но очень помогает это делать. На джаве рефакторинг в 2-10 раз веселее идет чем на питоне.

Відповісти

Підтримати

Grez

NewType 26.07.2014 12:41

Я разочаровался в Java как в языке так и в диаспоре/проектах под нее, думаю плотно переключаться на Scala и расти под нее.

Scala — под JVM.
Поэтому вас ожидает ещё немало подобного:

Почему Java жрет так много памяти? почему для средненького проекта нужно 1-2гб выделить под Heap, а на моем текущем используется 128 гб RAM облака и 8 процессоров...

Відповісти

Підтримати

anonymous 26.07.2014 12:38

NoSQL база и хранить объекты в JSON

И это будет работать с базой в 200 млн записей?

Відповісти

Підтримати

anonymous 26.07.2014 12:53

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

Відповісти

Підтримати

Alexander Makeev Магистр кофеварки 26.07.2014 12:32

Может попробовать найти работу по душе, чтобы жизнь не превращалась в день сурка? Если задолбало фомпочкоклепание — займитесь чем-то серьёзнее. Какие проблемы?

Відповісти

Підтримати

Rodion Bykov Senior Back-end Software Engineer 26.07.2014 12:25

Есть платформа Adobe ColdFusion, в которой сочетаются преимущества скриптовых языков с преимуществами java платформы, бизнес-приложения и вебсайты пишутся просто и быстро, деплой происходит на java серверы. Но есть проблема... никто ее не использует для новых проектов — немодно.

Відповісти

Підтримати

Sergei Epatov Staff RnD Engineer в Apptopia 29.07.2014 14:14

Иногда возникает дурацкое ощущение, что гиганты специально делают модными неудобные языки, технологии и платформы, а старую годноту загоняют в забвение. Чтобы процессы шли медленнее, и кризис индустрии отсрочился. Сравнить те же AS3 и JS, просто небо и земля.

Відповісти

Підтримати

Ще 1 коментар

Rodion Bykov Senior Back-end Software Engineer 29.07.2014 14:55

Судьба AS3 и Flex это действительно печаль. Имел удовольствие работать с ним, а сейчас смотрю на косяки, хаос библиотек и мнений в JS мире, скучаю по стройности и предсказуемости разработки на AS3. Недавно был в страховой, увидел привычный бизнес-интерфейс на Flex3, подумал как долго нужно было б писать те же бизнес-правила и многостраничные формы на JS.

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 26.07.2014 11:02

Grails мог бы сэкономить 80% времени разработки

На этапе разработки, или включая этап эксплуатации/развития?

NoSQL база и хранить объекты в JSON, отказ от hibernate-ов и сокращение разработки еще на 40%?

На этапе разработки, или включая этап эксплуатации/развития?
И откуда такие цифры? 5 систем по 3-5 лет каждая — это 15-25 лет, у вас, вроде как, поменьше опыта (исходя из других тем)
.

Знакомые PHP-шники смеясь делают за 1-2 дня, в то время как нам требуется месяц. Небольшая система, которую я один написал бы на Groovy за 7 дней в команде из 3-х человек на Java занимает полгода.

Когда-то делали небольшой эксперимент: джава против рейлс для небольшого проекта, делает 1 человек (который знает инструмент), потом другие люди туда добавляют фичу.
Результат: отличий по скорости разработки особых нет, новую фичу вкрутить оказалось быстрее на джаве чем в рельсовый проект, но, если я все правильно помню, то различия так же были не очень значительными.
Следовательно, разруха не в клозетах, а в головах ©
Ближе к вашему примеру, я не поверю что за счет языка трудоемкость увеличилась с 7 человеко-дней до 1.5 года. Но я могу придумать причины которые повлияют на качество результата.

Відповісти

Підтримати

Gabriel Angelos 26.07.2014 11:06

Grails

На этапе разработки, или включая этап эксплуатации/развития?

На любом этапе.

NoSQL

— особенно на этапе развития.
Представьте что у вас есть сформированная реляционная БД и вам надо добавить/убрать у класса переменную, либо модифицировать иерархию классов и маппингов на реляционной схеме, не раз видел невозможность что-то поменять в таком случае, пришлось писать рядом свои таблички, на уровне кода объекты мержить друг в друга — ад и гемор.

Ближе к вашему примеру, я не поверю что за счет языка трудоемкость увеличилась с 7 человеко-дней до 1.5 года.

Ваше право, вы можете не верить.
Но на позапрошлом проекте задачи по прикрутке 2-х сервисов, парсингу данных XSD<-> JAXB и обратно, сохранение в БД и небольшие валидации заняли ровно 7 месяцев в команде из 3-х человек. На новом проекте было похожее задание и я его сделал ровно за 7 дней на Groovy, даже данных было больше.

Відповісти

Підтримати

Ще 2 коментарі

Bogdan Shyiak SE or Dev 26.07.2014 11:31

2-х сервисов, парсингу данных XSD<-> JAXB и обратно, сохранение в БД и небольшие валидации заняли ровно 7 месяцев в команде из 3-х человек. На новом проекте было похожее задание и я его сделал ровно за 7 дней на Groovy,

Вы уверены что не упустили например: наличие/качесвто тестов, опыт команды разработчиков, качество ТЗ и тд.

NoSQL
— особенно на этапе развития.

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

Відповісти

Підтримати

Gabriel Angelos

Pavel Kruchina CTO 26.07.2014 11:37

Но на позапрошлом проекте задачи по прикрутке 2-х сервисов, парсингу данных XSD<-> JAXB и обратно, сохранение в БД и небольшие валидации заняли ровно 7 месяцев в команде из 3-х человек. На новом проекте было похожее задание и я его сделал ровно за 7 дней на Groovy, даже данных было больше.

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

А вообще — догадок можно строить много, но не видя кода, разговаривать смысла нет.

Відповісти

Підтримати

Gabriel Angelos

Pavel Kruchina CTO 26.07.2014 10:41

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

Проблема нашей отрасли в том, что инструмент выбирают по принципу «что хочет заказчик» или «что есть в сарае». Ну уж никак не «какой инструмент из всех существующих в нашем мире лучше подойдет для решения данной конкретной задачи».

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

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

Відповісти

Підтримати

Дулатжан Дыбыспаев Главный аналитик – ТОО "HIBRAIN" 21.09.2018 05:43

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

Відповісти

Підтримати

reality_hacker 26.07.2014 09:14

Ты как то предметно набрасывай, типа вот код на джаве, он кривой и некрасивый, а вот в груви даты сами конвертируются, памяти он совсем не ест, и работает быстрее джавы в 100 раз поэтому не нужно 8 процов и 128Г памяти.
Или например вот у меня на хибернейте такие то косяки, а на модном носкл все отлично работает, транзакции и развесистые супервложенные запросы летают наура.
А то может оказаться что у тебя в руках проблемы, и ты нам будешь искренне благодарен за их выравнивание когда дойдет до конкретных примеров.

Відповісти

Підтримати

Gabriel Angelos 26.07.2014 10:38

Хорошо, вот примеры. Здесь мы рассматриваем чистые возможности обоих языков.

Groovy полностью объектно-ориентированный язык, в нем размеры всех структур данных можно получить .size(), а не length(), length, size() как в Java, это просто странно. В Java примитивы — первоклассный геморрой и источник проблем.
Ну и предметно насчет примитивов в Groovy вы никогда не испытаете типичный WTF Java:

public static void main(String[] args) {
        int i = 10;
        something(i);
        System.out.println(i);
    }

    private static void something(int i) {
        i++;
    }

0) В Groovy не надо ставить точки с запятой и ловить null, это вроде бы мелочь, но очень приятно и мотивирует.
1) Прочитать строчки из файла и вывести на консоль
Groovy:

new File('E:\\Java_topics_list.txt').eachLine {println it}

Java(это еще хороший вариант, представьте что у вас JDK 6 без autocloseable) :

import java.io.BufferedReader;
import java.io.IOException;
import java.io.FileReader;

public class Sample {

    public static void main(String[] args) {
        try (BufferedReader br = new BufferedReader(new FileReader("C:\\testing.txt"))) {
            String line;
            while ((line = br.readLine()) != null) {
                System.out.println(line);
            }

        } catch (IOException e) {
            e.printStackTrace();
        }

    }
}

2) Примеры работы с датами на Groovy

def nowCal = Calendar.instance
y = nowCal.get(YEAR)
Date nowDate = nowCal.time
m = nowDate[MONTH] + 1
d = nowDate[DATE]
println "Today is $d $m $y"
nowCal.set DATE, 1
nowCal.set MONTH, FEBRUARY
println "Changed to $nowCal.time"

3) Расширяемость языка, в Groovy можно запросто добавить свои операции над объектами:
Account + Money, Account — Money, Account1 transfer Money to Account2
В Java о таком можно мечтать.

4) Родная поддержка коллекций/замыканий на уровне языка в Groovy

Map map = ['a':1, 'b':2]
map.each {key, value -> map[key] = value * 2}
assert map == ['a':2, 'b':4]

Closure doubler = {key, value -> map[key] = value * 2}
def doubleMethod (entry) {
    entry.value = entry.value * 2
}

doubler = this.&doubleMethod
map.each {doubler}
assert map == ['a':8, 'b':16]

5) Работа с XML, HTML, CSV, пока что пример для XML, например пробежаться по xml-ке и вытащить типы вложенных элементов language.
Java:

import org.xml.sax.SAXException;
import org.w3c.dom.*;
import javax.xml.parsers.*;
import java.io.IOException;

public class ParseXml {
  public static void main(String[] args) {
    DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
    try {
      DocumentBuilder db = dbf.newDocumentBuilder();
      Document doc = db.parse("src/languages.xml");

      //print the "type" attribute
      Element langs = doc.getDocumentElement();
      System.out.println("type = " + langs.getAttribute("type"));

      //print the "language" elements
      NodeList list = langs.getElementsByTagName("language");
      for(int i = 0 ; i < list.getLength();i++) {
        Element language = (Element) list.item(i);
        System.out.println(language.getTextContent());
      }
    }catch(ParserConfigurationException pce) {
      pce.printStackTrace();
    }catch(SAXException se) {
      se.printStackTrace();
    }catch(IOException ioe) {
      ioe.printStackTrace();
    }
  }
}

Groovy:

def langs = new XmlParser().parse("languages.xml")
println "type = ${langs.attribute("type")}"
langs.language.each{
  println it.text()
}

6) Параметризируемые конструкторы/методы/замыкания в Groovy
Представьте что у вас есть класс с 5-20 переменными и вам время от времени при создании разных объектов нужно инициализировать разное количество переменных, в Java будь добр пиши либо внутренний статический класс-билдер, который будет инициализировать переменные, либо 100500 конструкторов, либо столько же статических методов.
Пример в Groovy:

Foo foo = new Foo(param1: "one", param5: 5, param13: "thirteen");

7) Проверяемые исключения в Java — авторы знают толк в извращениях
Какой смысл в этих исключениях? Зачем нам ловить например SQLException, IOException, SAXException если в 99% случаях мы ничего сделать не можем и программа все равно должна уйти в штопор. Безопасней обвалить поток и залогировать исключение, чем оставлять пустые catch блоки, которые я видел не меньше миллиона раз. Но нет же! Я должен поймать проверяемое исключение, залогировать и бросить непроверяемое чтобы таки обвалить поток.
Нет слов...

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

Відповісти

Підтримати

Ще 38 коментарів

Pavel Kruchina CTO 26.07.2014 10:55

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

Вы сейчас влетели с Джавой в стадию конфликтов и закономерно нашли себе ~~молоденькую~~ другой язык в который «влюбились». Бывает.
Но на самом деле во всех языках есть свои прелести. Пых прост как молоток, прогеров как грязи, и коробка готовых поделок. js работает на любом утюге, асинхронен, очень объектен. Java имеет всю туже коробку поделок, только уже с прицелом на энтерпрайз.

Відповісти

Підтримати

Gabriel Angelos

Gabriel Angelos 26.07.2014 11:01

Не согласен с этой моделью, если люди постоянно ругаются и не понимают друг друга, то лучше разойтись. В плане инструментов: «Зачем использовать шуруповерт если есть дрель, отвертка и советский дюбель?» Вечна любовь к COBOL/ASM сродни антипаттерну золотой молоток на генном уровне. Если инструмент неудачен я выберу более удачный, вот и все.

Відповісти

Підтримати

Pavel Kruchina CTO 26.07.2014 11:21

Проблема в том, что на определенном этапе все ругаются.

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

Відповісти

Підтримати

Gabriel Angelos

Artyom Krivokrisenko 26.07.2014 10:59

new File(’E:\\Java_topics_list.txt’).eachLine {println it}

Когда файл считывают конструкцией new File, один котик на планете начинает плакать.

Не пишу на джаве или груви, но такое чувство, что автор ностальгирует по тому, что было в дотнете во второй (если даже не в первой) версии.

Відповісти

Підтримати

Gabriel Angelos

Vasya Pupking 26.07.2014 11:12

типичный WTF Java:
public static void main(String[] args) {
int i = 10;
something(i);
System.out.println(i);
}
private static void something(int i) {
i++;
}

и что же вам не нравится в поведении приложения в этом примере? Это не в Java проблемы а в чьих-то базовых знаниях, что не знает, чем отличается передача по ссылке от передачи по значению...

Відповісти

Підтримати

Gabriel Angelos

Gabriel Angelos 26.07.2014 11:17

Я в курсе, иначе бы не привел. Только вот такого кода пруд пруди, а ведь это базовые вещи. ИМХО неудобная и стремная вещь, лучше бы ее не было как и примитивов.

Відповісти

Підтримати

Pavel Kruchina CTO 26.07.2014 11:28

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

Хотя опять таки, если понимаешь, что такое «ссылочный тип» — то проблем не будет.

Відповісти

Підтримати

Gabriel Angelos

Vasya Pupking 26.07.2014 11:57

не пользуйтесь примитивами и не будет вам примитивов. В чем WTF в примере так и не понял...

Відповісти

Підтримати

Gabriel Angelos

reality_hacker 26.07.2014 12:01

1)

Files.readAllLines(path, charset).forEach(System.out::println);

Відповісти

Підтримати

Gabriel Angelos

Gabriel Angelos 26.07.2014 17:34

Здесь мы рассматриваем чистые возможности обоих языков.

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 26.07.2014 19:22

Files.readAllLines(path, charset).forEach(System.out::println);

Здесь мы рассматриваем чистые возможности обоих языков.

Уууу, похоже открыта тайна почему 3 человека писали 7 месяцев простой проект на джава: Среди них не было людей которые знают этот язык :)

Відповісти

Підтримати

Gabriel Angelos

reality_hacker 26.07.2014 21:40

Даже на 7-ой жабе это можно легко написать намного проще чем криворукий ТС:

for(String s: Files.readAllLines(...)) System.out.ptintln(s);

Відповісти

Підтримати

Vasya Pupking 26.07.2014 19:23

чем же принципиально отличаются эти два подхода?

Відповісти

Підтримати

Gabriel Angelos

reality_hacker 26.07.2014 12:04

2) JodaTime умеет приблизительно все то же

Відповісти

Підтримати

Gabriel Angelos

Gabriel Angelos 26.07.2014 17:35

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

Відповісти

Підтримати

Vasya Pupking 26.07.2014 19:23

Java 8

Відповісти

Підтримати

Gabriel Angelos

Bogdan Shyiak SE or Dev 26.07.2014 19:24

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

Встраивать работу с датами в язык? А где такое сделано? И накуя?

Відповісти

Підтримати

Gabriel Angelos

undefined pointer 26.07.2014 20:22

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

или все же создают? А потом гордо отвечают — JodaTime умеет приблизительно все то же!

но раз это реализовано тонной библиотек — ура! это ж не в язык всобачено!

НЕ вставлять в ЯП — это такая самоцель что-ли? ;)
а может самоцель — убрать из языка средства для создания своих типов?

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 26.07.2014 20:52

НЕ вставлять в ЯП — это такая самоцель что-ли? ;)

А где такое сделано?

Відповісти

Підтримати

undefined pointer

idOne Арбузный 26.07.2014 21:05

Головне не де так зробили ,а чому в жабі цього не зробили

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 27.07.2014 00:14

а чому в жабі цього не зробили

Патамуша это никаму нах не надо :)

Відповісти

Підтримати

idOne Арбузный

Євген Козлов Front-end developer в SoftServe 26.07.2014 23:54

мне кажется, такое выносится из «ядра», но включается в поставку компилятора.
такое себе STL

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 27.07.2014 00:13

мне кажется, такое выносится из «ядра», но включается в поставку компилятора.
такое себе STL

Такое не включают в язык ваапшэ. То что вы назвали «включается в поставку компилятора» называется стандартная библиотека. Возвращаясь к примеру ТСа, это похоже на каленарь-АПИ, оно есть в джава, вроде, с версии 1.1. А йода (с небольшими изменениями) вошла в 8-ку.
Суть претензии не ясна.

Відповісти

Підтримати

Євген Козлов

Євген Козлов Front-end developer в SoftServe 27.07.2014 00:28

язык как стандарт? ну, да, конечно.
но если говорить про java, насколько важно разработчику использовать только «средства самого языка» и изучать «голый язык»?
в отрыве от стандартной библиотеки.
а том числе, и какой смысл в споре — что куда включено?

Відповісти

Підтримати

reality_hacker 26.07.2014 12:06

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

Відповісти

Підтримати

Gabriel Angelos

Andriy Kuba Астронавт в Ciklum 26.07.2014 15:04

На скала не писав, але судячи по цьому коментарі і по прикладу автора ... Якщо вам хочеться «свободи» — спробуйте старий добрий Lisp, думаю він вставить і скалу і інше подібне.

Почитайте історію ІТ, чому ми маємо C та Java і чому на них «підвис» інтерпрайз. Вони зменшують число важко вловимих помилок. Думаю, було б добре взагалі викинути половину «цукру» і ввести ще жорсткіші правила, як то, щоб компілятор не допускав однакових імен змінних у всьому класі, а не лише в області видимості і т. д.

Чому зараз вертається мода на різні «слабко типізовані мови\бд», на зразок сервер сайд джаваскрипт \ носкл і т.д. — тому що в багатьох проектах для широкого вжитку, як то інтернет магазин за 7 днів чи стартап по продажу піци — треба робити швидко, і помилки не спричинять втрат мільйонів, тим паче при скрамі — «ви не можете відсортувати список піци по інгрідієнтам? вносимо в скрам ліст, через дві неділі все буде готово»

Я маю значний досвід зі «старим» носкл :) - IBM Domino, сайти на ньому писати — жодних проблем, додаєш\видаляєш які хочеш поля і як хочеш. А от системи аналізу даних — це жесть, кров і сльози. Що я хочу сказати — пишеш сайт\магазин\формошлепку — носкл саме те що треба, пишеш білінг систему\аналітику — реляційна база.

Відповісти

Підтримати

Grez 27.07.2014 07:47

можно кложур, который тоже под жвм :-)

Відповісти

Підтримати

reality_hacker 26.07.2014 12:07

4 — есть в джава 8

Відповісти

Підтримати

Gabriel Angelos

reality_hacker 26.07.2014 12:07

5 — белые люди делают такие задачи каким нибудь xpath

Відповісти

Підтримати

Gabriel Angelos

reality_hacker 26.07.2014 12:09

6 — это называется — именованные параметры, но это принимается, полезная фича.

Відповісти

Підтримати

Gabriel Angelos

Vasya Pupking 26.07.2014 12:20

в Java решается добавлением в проект либы типа Lombok, которая автоматом строит билдер (да, не именнованные параметры но тоже удобно и писать ничего не надо).

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 26.07.2014 12:23

6 — это называется — именованные параметры, но это принимается, полезная фича.

Именованные параметры, то именованные, но __не принимаетсо__.
Если у вас метод принимает 100500 параметров, это значит что у вас проблемы с дизайном.
Фича не столько полезная, сколько прикольная. (Но может у вас есть примеры/аргументы лучше чем пример от Gabriel Angelos)

Відповісти

Підтримати

reality_hacker 26.07.2014 12:37

Ладно, может с именованными параметрами и вкусовщина, хз.

Відповісти

Підтримати

Anton Naumov SSE в Just Techologies AS 26.07.2014 13:24

Плюс один к проблемам дизайна. Три параметра на функцию — правило которое можно нарушать только сознательно. Я иногда разворачиваю объекты цепочку параметров для statless вычислений — тестировать удобнее. Но если подходить православно — можно ввести допонительный dto.
А фича полезная только в случае, если у параметров есть значения по-умолчанию иначе разницы никакой. Но прикольная, согласен

Відповісти

Підтримати

reality_hacker 26.07.2014 12:10

7 — эксепшн декларируют контракт, без этого взглянув на метод ты никогда не узнаешь какие ошибки в нем могут произойти, а контракт тебя заставит их все обработать. Пустые блоки — это поцоватые проблемы гавнокодеров

Відповісти

Підтримати

Gabriel Angelos

Gabriel Angelos 26.07.2014 17:47

а контракт тебя заставит их все обработать.

Предложите вменяемый вариант обработки падающего SQLException-а помимо обваливания потока.

Відповісти

Підтримати

Дмитрий Швейкус 26.07.2014 20:15

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

Відповісти

Підтримати

Gabriel Angelos

reality_hacker 26.07.2014 21:41

retry?

Відповісти

Підтримати

Gabriel Angelos

Gabriel Angelos 26.07.2014 10:58

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

Відповісти

Підтримати

Ще 9 коментарів

reality_hacker 26.07.2014 12:12

Зависимости очевидно на потребление памяти не влияют, но некоторые фреймворки действительно прожорливы. Но их можно не юзать если критично.
А вообще 128ГБ памяти это месячная ЗП программера наверное, дешевле их втыкнуть чем чето серьезно оптимизировать.

Відповісти

Підтримати

Gabriel Angelos

idOne Арбузный 26.07.2014 21:07

дешевле их втыкнут

тут можна тільки сказати, що місце в ДЦ не гумове і швидко закінчується з таким підходом

Відповісти

Підтримати

reality_hacker 26.07.2014 21:43

Практика показывает что 128ГБ памяти хватает для 98% апликух на джаве что бы обрабатывать несколько сотен QPS без какой то супероптимизации. Место в датацентре будет заканчиваться только для апликух типа фейсбука, тогда можно и пооптимизировать.

Відповісти

Підтримати

idOne Арбузный

Дмитрий Олейник Працює в Luxoft 26.07.2014 21:45

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

А вообще 128ГБ памяти это месячная ЗП программера наверное, дешевле их втыкнуть чем чето серьезно оптимизировать.

Відповісти

Підтримати

reality_hacker 26.07.2014 21:48

Первая ссылка в гугле, 128ГБ ЕЦЦ — 1.5К баксов, как я и говорил пол ЗП синьёра. eshop.macsales.com/...DOaEaAqTq8P8HAQ

Відповісти

Підтримати

Дмитрий Олейник

mobile mobile 26.07.2014 21:52

та какое, нада смотреть плату расширения например под НР сервер на которой стоит 128 гигов, она наверно пару штук стоит

Відповісти

Підтримати

reality_hacker 26.07.2014 21:56

Вот за 6-есть штук целый сервер www.alinc.com/...qPacaAsi08P8HAQ

Відповісти

Підтримати

Дмитрий Олейник Працює в Luxoft 27.07.2014 01:13

Ну вот, собственно:
en.wikipedia.org/...sts#cite_note-5

Помимо этого, есть ещё экспуатация — не очень понятно, из чего складывается стоимость, но 1GB под tomcat за год стоит каких-то дурных денег, измеряется в $K.
Откуда — не спрашивайте, сам не понимаю.

Відповісти

Підтримати

reality_hacker 27.07.2014 10:03

Ну вот, собственно:
en.wikipedia.org/...sts#cite_note-5

Моя непонимать что ты сказать хотел, по поиску в гугле 16ГБ стоит $190, или полторы штуки 128ГБ, все как я и говорил.

Помимо этого, есть ещё экспуатация — не очень понятно, из чего складывается стоимость, но 1GB под tomcat за год стоит каких-то дурных денег, измеряется в $K.
Откуда — не спрашивайте, сам не понимаю.

Ну я тебе могу и за $М продать, не вопрос.

Відповісти

Підтримати

Дмитрий Олейник

Artyom Krivokrisenko 26.07.2014 04:50

Grails мог бы сэкономить 80% времени разработки, но нам его использовать не дадут, потому что заказчик считает Groovy детским развлечением и готов платить в 5 раз больше, или его убедили в этом.

Разумеется, заказчик идиот. Или наоборот, он понимает, что через полгода все разрабы в очередной раз сбегут на +100 в соседнюю контору, а ему прийдется искать на рынке специалистов, имеющих опыт работы с **9 знает каким набором фреймворков, языков и прочих штучек, согалсных разбираться с чужим кодом.

NoSQL база и хранить объекты в JSON, отказ от hibernate-ов и сокращение разработки еще на 40%?

А если задачи таките, что NoSQL ну никаким боком не подходит?

заказчик хочет переиспользовать свой SQL-server и «решения» под него из подпорок и костылей...

У заказчика уже есть какая-то экосистема, куда он хочет добавить еще один компонент. Разумеется, нужно эту экосистему прибить и все переписать с нуля, потому что в команде разрабочтиков завелся хипстер, который любую задачу решает NoSQL и кложурой.

Відповісти

Підтримати

Студент 26.07.2014 01:54

Кто платит, тот и музыку заказывает. Может проблема не в языке / платформе / фреймворке, а в вас ?

Відповісти

Підтримати

Макс Матюхин программист в Badoo 26.07.2014 01:13

думаю плотно переключаться на Scala и расти под нее

косяки в скале, как например в этом докладе www.youtube.com/...h?v=TS1lpKBMkgg — не пугают ?

Відповісти

Підтримати

Лего 26.07.2014 02:23

автора таким не испугать, 4ре крупных проекта на java за плечами и тысячи коментариев на доу

Відповісти

Підтримати

Макс Матюхин

anonymous 26.07.2014 01:08

-

Відповісти

Підтримати

Java Adept 26.07.2014 01:03

думаю плотно переключаться на Scala и расти под нее.

На кложур посмотри еще

Відповісти

Підтримати

mobile mobile 26.07.2014 01:01

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

Відповісти

Підтримати

Yurii V 26.07.2014 10:53

Rust
cburgdorf.wordpress.com/...-of-the-future

Відповісти

Підтримати

Mr Grinch 26.07.2014 00:58

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

Да, дофига заказчиков твердо «знают» при помощи каких инструментов и фреймворков/CMS должна быть выполнена задача, и пох, что «простенький», но до тошноты кастомизированный интернет-магазин я подниму за пару-тройку недель либо на ненавороченном фреймворке, либо хоть с нуля, в то время как на втискиваемом ими вордпрессе придется несколько месяцев ставить костыли, распорки, подтирать гoвно и фиксить баги, проклиная себя за корявость принимаемых решений, тонны вынужденного индусского кода и прочие доводящие до нервного хихиканья маразмы (это к твоему замечанию о «смеющихся ПЫХарях» и пхрелестях готовых ЦМС), и так, упаси Б-г, после каждого обновления самого ВП, либо каких-то ключевых задействованных модулей.

P.S. Да, да, да! Но при этом дофига заказчиков щедро оплачивают свои прихоти, поэтому мне в упор не понятна твоя зависть к джумло-макакам, которые высырают по интернет-магазину каждые два дня. Там просто нечему завидовать. Тех, которые могут родить пять статических ХТМЛ страничек а-ля под Татяныча и взять за это пятизначную сумму — единицы. Остальные по факту если не сосут с голоду зaлупу, то пребывают в перманентном стрессовом шоке от каждого нового заказчика, из-под которого надобно еще вытащить хоть какую-то спецуху.

Відповісти

Підтримати

anonymous 26.07.2014 01:18

-

Відповісти

Підтримати

Ще 7 коментарів

Pavel Kruchina CTO 26.07.2014 11:45

Посмотрите глазами заказчика:
С вордпрессом все предсказуемо. Да, пусть впихивать туда функции чуть дольше(по вашим словам), однако одна команда сможет поддерживать все проекты.

Відповісти

Підтримати

Mr Grinch 26.07.2014 14:14

Ага, мой любимый аргумент. И кто только им эту туфту внушает? Не вы часом стараетесь? :)
Сами хоть понимаете, что это именно «глазами заказчика»? Накастомизировать можно так, что никто в здравом уме потом не возьмется поддерживать, и до срaки, вордпресс лы там был, джумла или свой гипер-цмс-костыль (зачастую, долбаться с последним и то приятней).

Відповісти

Підтримати

Pavel Kruchina CTO 26.07.2014 14:25

В самом худшем случае, внутри вордпресса впаяют свою цмс. В случае с собственным костылем — мы имеем дело с велосипедом в любом случае. С нулевым количеством доков и тому подобного.

Відповісти

Підтримати

Mr Grinch 26.07.2014 14:34

В самом худшем случае, внутри вордпресса впаяют свою цмс.

Угу. Только поправка: в чуть более чем докуя случаев; и не ЦМС, а кипу индусского гoвнокода. И ковыряться в таком дерьме куда хуже чем в самописном (даже не своем) костыле с нулевым кол-вом доков, зато более-менее адекватно написанном.
Заказчики, которые уже обожглись, подтвердят безсмысленность поисков священной коровы в виде «готовой» CMS, в которой «любая макака легко заменяема на новую, ведь та за полдня разберется» ©
А вообще, у вашего мифа ноги уж с очень интересного места растут...

В случае с собственным костылем — мы имеем дело с велосипедом в любом случае.

Напоминаю, все что шло после ныне покойной PHP-Nuke, а возможно и раньше — априори велосипед.

Відповісти

Підтримати

Pavel Kruchina CTO 26.07.2014 14:39

Нда, классический аргумент «хороший A лучше, чем плохой Б».
Повторюсь ещё раз: При прочих равных (одинаковой кривизне рук) использование популярных технологий приводит к более поддерживаемым результатам, чем использование собственных наработок.

А так то да, дело не в фреймворке, дело в программисте.

Відповісти

Підтримати

Mr Grinch 26.07.2014 14:47

А прочих равных зачастую и быть не может. Не забыли, что сами по себе многие «популярные технологии» являют собой тот еще выкидыш мысли нарика-имбецила?

Ну а остальном, шо ж, удачи в поддержке «результатов» ;) «Довольных» клиентов можете сразу направлять ко мне на «лечение».

Відповісти

Підтримати

Євген Козлов Front-end developer в SoftServe 26.07.2014 23:58

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

Відповісти

Підтримати

Mr Grinch 26.07.2014 00:27

Знакомые PHP-шники смеясь делают за 1-2 дня, в то время как нам требуется месяц.

Так то они над своей ЗП смеются ))

А у вас, батенька, кризис среднего возраста походу в самом разгаре, и Джава тут ни при чем.

Відповісти

Підтримати

anonymous 26.07.2014 22:00

та ладно норм ПХП может спокойно получать 4,5К

Відповісти

Підтримати

Ще 5 коментарів

Grez 27.07.2014 07:52

норм жаба, может спокойно получать 10к+, такто.

Відповісти

Підтримати

Denys Ievstratenko Senior Java Developer 27.07.2014 12:15

у нас?

Відповісти

Підтримати

Grez

Gremlin 28.07.2014 22:54

подходим, меряемся, не стесняемся ))

Відповісти

Підтримати

Grez

Mr Grinch 28.07.2014 22:59

Да я в курсе, сам вот уже почти подобрался к этому заветному «потолку», но речь не обо мне ведь была, и не о тех, которые получают, речь была о «хихикающих мальчиках», которые не понимают, нах чего-то учить, когда можно разворачивать 100-баксовые сайтики на Джумле за два дня. Есть примеры, чтоб такие организмы получали

4,5К

?

Відповісти

Підтримати

Artyom Krivokrisenko 29.07.2014 03:29

мб в фейсбуке?

Відповісти

Підтримати

Підписатись на коментарі

Ваша пошта

Не підписуватись