А, тогда полгода с ставкой сеньора каждому, не меньше, да.

Потом ещё юнит тесты попросят написать, ну и интеграционные и нагрузочные на всякий случай

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

Вы упускаете самый прикол: > С полным покрытием документации

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

Чем затюнить http apache client? PoolingConnMgr на 1000 запросов, но даже 100 потоков не дают нагрузку больше чем 10 запросов в секунду

Вы упускаете самый прикол: > С полным покрытием документации

Это чё как? Чё прамо тестами документацию покрыть? А документация на чем написяна? На яваскрипт небось?

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

Да, описание того, что она должна делать, есть.

Да, описание того, что она должна делать, есть.

Ну тогда худшую оценку можно порезать на 15-20%. Не более того.

В общем браться за это с дедлайном в три месяца и какими-либо личными рисками я бы не стал.

Коpоче говоpя, если у кого-то есть желание – пишите. Заpплата будет, и будет хоpошая. Нужно два-тpи человека.

Народ, по теме java spring и все такое, кто нибудь юзал QueryDSL ? Я говорю не про проекты а-ля 10'000 юзеров, болото и ни какого перформанса. Хочу спросить про серьезные проекты с большой нагрузкой и регулярными замерами перформанса. Какие у этой либы (QueryDSL) плюсы использования?

Если есть возможность, то лучше взять JOOQ и не связываться с JPA вообще, а как следствие и с QueryDSL, который надстройка

JOOQ умеет делать то же, что и QueryDSL: генерировать Type Safe модель вашей схемы данных для создания type safe запросов, но без JPA

Если есть возможность, то лучше взять JOOQ и не связываться с JPA вообще, а как следствие и с QueryDSL, который надстройка

Дмитрий, можете изложить по подробнее? А-ля плюсы минусы, почему?

Тут претензия скорее не к QueryDSL, а к JPA\Hibernate. Он делает общение с БД слишком непрозрачным.

Народ, по теме java spring и все такое, кто нибудь юзал QueryDSL ? Я говорю не про проекты а-ля 10'000 юзеров, болото и ни какого перформанса. Хочу спросить про серьезные проекты с большой нагрузкой и регулярными замерами перформанса. Какие у этой либы (QueryDSL) плюсы использования?

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

Тут претензия скорее не к QueryDSL, а к JPA\Hibernate. Он делает общение с БД слишком непрозрачным.

Ок. Понятно, спасибо.

Тут претензия скорее не к QueryDSL, а к JPA\Hibernate. Он делает общение с БД слишком непрозрачным.

я бы не сказал, можно и на jpa/hibernate производительно работать

Ок. Понятно, спасибо.

если не тошнит, то jpa не выкидывайте, это должен быть взвешенный и осознанный шаг

JPA не зло ни в одном месте

я бы не сказал, можно и на jpa/hibernate производительно работать

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

(сейчас набегут хипстеры)

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

в jpa/hibernate это все можно легко проконтроллировать

в jpa/hibernate это все можно легко проконтроллировать

каким образом?

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

Александр, это все да когда речь идет о малюсеньком проекте до 20 разработчиков. Потом эти финты ушами будут больно бить.

Александр, это все да когда речь идет о малюсеньком проекте до 20 разработчиков. Потом эти финты ушами будут больно бить.

Вам нужен перформанс или гибкая масштабируемость кода? Вы уверены что у вас bottleneck именно в обращении к базе?

Александр, это все да когда речь идет о малюсеньком проекте до 20 разработчиков. Потом эти финты ушами будут больно бить.

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

Вам нужен перформанс или гибкая масштабируемость кода? Вы уверены что у вас bottleneck именно в обращении к базе?

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

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

Это был один из моих аргументов, спасибо.

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

Мне кажется, в первую очередь надо определелиться: JPA или не JPA. А QueryDSL - это производная от первого решения будет

Мне кажется, в первую очередь надо определелиться: JPA или не JPA. А QueryDSL - это производная от первого решения будет

Дмитрий, да предположим выбор сделан jpa.

Стали бы в этом случае ее применять?

Стали бы в этом случае ее применять?

Мне кажется, альтернативы в рамках JPA вас не обрадуют

Стали бы в этом случае ее применять?

Тогда да, стал бы. Потому что она (QueryDSL) генерирует вашу модель данных для создания type-safe запросов и с этим она справляется нормально. Такой подход точно лучше, чем писать HQL\JPQL запросы в виде текста.

У нас в проекте мы рабоатет с QueryDSL и проблем он нам не создает.

Именно HQL/JPQL вообще не очень нравятся (мне лично) тем, какой довольно странный идеологически (и в чуть меньшей степени практически) слой абстракции они предоставляют.

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

Тогда да, стал бы. Потому что она (QueryDSL) генерирует вашу модель данных для создания type-safe запросов и с этим она справляется нормально. Такой подход точно лучше, чем писать HQL\JPQL запросы в виде текста.

Как на счет нечитаемости? Представьте что к вас 300 разработчиков сможете объяснить им причины выбора?

Как на счет нечитаемости? Представьте что к вас 300 разработчиков сможете объяснить им причины выбора?

Когда вас 300 разработчиков, и проект уже есть, нет никакого смысла вот так посреди цикла разработки обсуждать "а почему выбрано это решение".

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

Ну просто мне кажется есть смысл или писать нативные запросы (если вас настолько парит точность и/или перформанс), или хотя бы пользоваться Criteria API для типобезопасности, или вообще какими-то решениями типа спрингдаты, если всё примитивно, и внутрянка запросов пока кажется вам очевидной.

Как на счет нечитаемости? Представьте что к вас 300 разработчиков сможете объяснить им причины выбора?

Читаемость текста привычнее и проще, конечно. Эти запросы лучше упаковывть в отдельные методы с понятными именами как минимум.

Ну просто мне кажется есть смысл или писать нативные запросы (если вас настолько парит точность и/или перформанс), или хотя бы пользоваться Criteria API для типобезопасности, или вообще какими-то решениями типа спрингдаты, если всё примитивно, и внутрянка запросов пока кажется вам очевидной.

Да все именно так, у нас все примитивно, спасибо.

Как на счет нечитаемости? Представьте что к вас 300 разработчиков сможете объяснить им причины выбора?

Основной плюс я выше описал: это type safety. Других плюсов тут, на мой взгляд, нет

Читаемость текста привычнее и проще, конечно. Эти запросы лучше упаковывть в отдельные методы с понятными именами как минимум.

Засчитано.

Основной плюс я выше описал: это type safety. Других плюсов тут, на мой взгляд, нет

Засчитано.

Если есть возможность, то лучше взять JOOQ и не связываться с JPA вообще, а как следствие и с QueryDSL, который надстройка

by the way почему QueryDSL = надстройка над JPA? его можно и без JPA юзать, разве нет? https://github.com/querydsl/querydsl/tree/master/querydsl-sql

by the way почему QueryDSL = надстройка над JPA? его можно и без JPA юзать, разве нет? https://github.com/querydsl/querydsl/tree/master/querydsl-sql

Да, вы правы. Никогда его не использовал вне jpa, поэтому пропустил, что он и native sql стал поддерживать и даже mongodb

by the way почему QueryDSL = надстройка над JPA? его можно и без JPA юзать, разве нет? https://github.com/querydsl/querydsl/tree/master/querydsl-sql

Хм, а чем он вообще отличается от jOOQ?

by the way почему QueryDSL = надстройка над JPA? его можно и без JPA юзать, разве нет? https://github.com/querydsl/querydsl/tree/master/querydsl-sql

Так и есть

Не обязательно жпа врубать для нее

Хм, а чем он вообще отличается от jOOQ?

честно не знаю, базовый функционал плюс-минус одинаковый. может, кто ещё из присутствующих поделится опытом)

честно не знаю, базовый функционал плюс-минус одинаковый. может, кто ещё из присутствующих поделится опытом)

Лицензией, jooq платная штука

Лицензией, jooq платная штука

Только для использования с Oracle и MS SQL

Только для использования с Oracle и MS SQL

и ещё десятком других бд

и ещё десятком других бд

ну если рассматривать в связке с MySQL, PostgreSQL, например для них jooq по опен сорс лицензии кроме лицензии различия интересуют))

Привет всем, Есть у кого-то опыт работы со Spring XD? Хотел задать один-два quick вопроса.

Привет всем, Есть у кого-то опыт работы со Spring XD? Хотел задать один-два quick вопроса.

Это у тебя блог на смартпрогрессе?)

Это у тебя блог на смартпрогрессе?)

Да) спасибо за ссылку, попробую там узнать

Это конченный чат по спрингу

не рекомендую его

а кто еще раз кинет ссылку на него - уйдет в бан навсегда

Это конченный чат по спрингу

Окей... а есть какой-то ещё чат спринговый?)

Окей... а есть какой-то ещё чат спринговый?)

там тебе все равно не помогут, ибо там либо нубы, либо неадекватные великовозрастные админы-вайтишники с курсов

Окей... а есть какой-то ещё чат спринговый?)

задавай здесь вопросы или в @javastart

там тебе все равно не помогут, ибо там либо нубы, либо неадекватные великовозрастные админы-вайтишники с курсов

а кто мне со спрингом поможет?

а кто мне со спрингом поможет?

@scala_ru

а кто мне со спрингом поможет?

@jvmjobs

а кто мне со спрингом поможет?

здесь тоже большое количество спринговодов

Стали бы в этом случае ее применять?

Есть еще myBatis на горизонте...

Вопрос Если мы пишем BeanPostProcessor и накручиваем логику метрик вокруг каждого метода - это же postProcessAFTERInit ? а не Before?

Вопрос Если мы пишем BeanPostProcessor и накручиваем логику метрик вокруг каждого метода - это же postProcessAFTERInit ? а не Before?

у интерфейса BeanPostProcessor есть и before метод, и after

в кейсе с метриками - after

но обычно для таких вещей используют AOP - http://rprakashg.io/blog/posts/using-spring-aop-for-metrics-collection/

каким образом?

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

Александр, это все да когда речь идет о малюсеньком проекте до 20 разработчиков. Потом эти финты ушами будут больно бить.

Какие финты то?

Как на счет нечитаемости? Представьте что к вас 300 разработчиков сможете объяснить им причины выбора?

О какой нечитаемости речь? Все отлично читается и понимается

Как на счет нечитаемости? Представьте что к вас 300 разработчиков сможете объяснить им причины выбора?

Какие то предположения с потолка, нет?

Либо умеешь в орм, либо нет

Либо не хочешь разбираться с этими унылыми орм

Либо не хочешь разбираться с этими унылыми орм

Почему унылыми то?

Надо просто сразу признать и сказать «неосилил»

Надо просто сразу признать и сказать «неосилил»

Ну вот да. Или не было причин их использовать, например

Ну вот да. Или не было причин их использовать, например

+

Какие то предположения с потолка, нет?

Конечно, "предположения". И конечно же "с потолка". И конечно же ни кто не осилил. И конечно, в вопросе все это было.

Конечно, "предположения". И конечно же "с потолка". И конечно же ни кто не осилил. И конечно, в вопросе все это было.

ну вот и ладушки