Минуя печать? А что, по вашему книги в электронном виде пишутся быстрее? По-моему они уже все лет 20 как пишутся в текстовом процессоре. Безо всяких исключений. И время очевидно уходит именно на написание, а уж точно не на печать. Я думаю на нормальную книгу нужно хотя бы полгода.
Безалаберность? Да просто нормальные авторы понимают, что такого рода книги никому не нужны (я не говорю обо всех их видах). Их устаревание до момента выхода в свет всем очевидно. Реально живут только книги по продукту, которые пишутся и развиваются в виде wiki сразу, и обновляются постоянно. А печатную форму приобретают просто путем применения другого форматирования.
Узкопрофильные книги имеют свойство устаревать мгновенно. Обычно еще до выхода в свет. А типичный случай — когда в момент выхода книга описывает версию продукта, которой года три. По тем продуктам, на которых я лично сегодня работаю, одна книга вышла в 2010, а второе ее издание начато в 2015 — и не написано. Так вы какими книгами предлагаете пользоваться — не напечатанными (т.е. в сущности, все равно интернетом), или устаревшими лет на 5?
>И это работает! А 95% людей, услышав слово webservice, полезли бы в JEE.
Ну как бы вам сказать… вот то что вы так пишете, возникло вовсе не само по себе — а в результате обобщения опыта JavaEE. И более того, насколько я помню, JAX WS это часть именно JavaEE как спецификации. То что оно вообще (я тут про все фреймворки, а не только про JAX WS само собой) стало доступно отдельно — это именно результат развития спецификации и множества ее альтернативных реализаций. Причем развития многолетнего.
>к вам придет добрый дядя DBA и скажет, что все данные будут вот в этой одной БД, а БД будет в Житомире.
Если бы. Вы сначала напишете все в виде join из четырех таблиц, а потом придет тот же самый дядя, и скажет вам, что это будет четыре разные базы (хоста). За две недели до релиза. И это реальный случай, между прочим.
>Ваши аргументы сводятся к вашему личному опыту сравнения с решениями, написанными по-ходу неквалифицированными программистами. И Вы делаете вывод, что виновато отсутствие JEE. Отчасти, конечно, Вы правы.
А я и не говорю, что я везде прав. Это, если угодно, был намек. что программисты у нас такие, какие есть. И не у нас тоже — подрядчики не лучше, я видел вживую, какого качества код пишут в IBM, лучше бы его развидеть. Набрать где-то лучше — это зачастую большущая проблема. Набрать таких, которые способны реализовать сами контейнер — ну вы сами только что написали, что мало кто понимает, как он работает. Не видите противоречия? )))
Слушайте, ну не надо утрировать. Я вам могу еще раз повторить — у меня было с десяток вполне успешных проектов сравнительно разного размера, и нигде, повторяю — нигде выбор JavaEE не был основан на том, что дядя купил Weblogic. Его выбрали разработчики. А поскольку проекты были успешные — то выбор был правилен.
Выбрал бы я его сейчас? А вот не факт. Может быть выбрал бы karaf — но при этом нормального JavaEE уровня реализации многих вещей я там не вижу.
А все ваши соображения — они вполне себе разумные и не вызывают отторжения — если выводы не обобщать на все проекты и всех разработчиков. Потому что «без нормальных тестов» — это давно неправда. Где-то с EJB 3 примерно.
Ну, с ant проще перевести на что угодно. Реальные проблемы в сборке обычно начинаются тогда, когда у нас в проекте кучка зависимостей, как внешних, так и внутренних, которые обновляются время от времени, и надо следить за их версиями, их совместимостью и т.п.
ant этого всего почти не умеет (даже с ivy). gradle и maven умеют, но делают по разному, я не могу сказать, что какой-то подход заведомо лучше. Лично для себя я предпочитаю maven, по той простой причине, что формат pom.xml — он читается любым инструментом, на любом языке, gradle же неявно предполагает, что у вас есть сам gradle, и почитать скажем метаданные проекта без него — это целая история (и кстати, в репозиторий обычно кладут все тот же pom).
Стандартный ответ — вы обобщаете свой ограниченный опыт на всех, и делаете ошибку. Нет, не JTA вовсе. А скорее управляемость кода в целом, как при разработке, так и в эксплуатации. В самом широком смысле.
История о том, что все глухо лежит, пока не разбудят админа, больше всего похожа на байку. Я лично про такое никогда не слышал — просто потому, что таймауты никто не отменял. А я уже с 2000 года на J2EE. Начиная с EJB 2, который реально был так себе. Только это давно неправда.
remote EJB нарушает транзакционность? С каких это пор? Где вы взяли такой фиговый контейнер?
А насчет лучше и проще… ну может в вашем мире так, а я повторюсь, все крупные проекты, которые я видел и которые были сделаны без контейнера (на сегодня это либо JavaEE либо OSGI) — на них смотреть было больно. Именно потому, все все, буквально, что было изобретено на замену штатным средствам JavaEE, все не работало. В одном своем проекте у меня было примерно полсотни мелких компонент, из которых где-то 40 жили в Weblogic, а остальные 10 были standalone приложениями. Так вот, мороки с этими десятью было не в пример больше — при том что по сложности они были несравнимо меньше.
Так что для меня контейнер дает совсем другое — причем простое и очевидно. Модульность — в виде каких-либо стандартных компонент, которе начиная с EJB3 пишутся легко и непринужденно, а до этого делались с помощью спринга, обозримость runtime в целом, когда контейнер предоставляет скажем консоль, откуда можно посмотреть JMX и порулить ими, запустить и остановить компоненты, и прочая. И когда у вас в проекте этих компонент с полсотни — это уже нифига не мелочи. Попробуйте на пару сотен микросервисов просто порты пораспределять без инструмента — и каково оно?
Короче — я не вижу этого вашего «лучше и проще». Может оно и существует где-то (скажем, для высоконагруженных приложений) — а в среднем проекте, где нагрузки особой нет, пользователей скажем тысяч десять (а это, между прочим, масштаб интранета крупнейших банков), из велосипедов получается одно барахло.
Гм. Вот знаете, у нас в соседнем проекте оказывается собирали все maven второй версии. Я уже забыл, когда у меня он был, лет семь наверное прошло с тех пор. При этом оно а) работает б) с тем же репозиторием в) разницы в pom.xml нет никакой. Инструменту 10 лет, он используется, и все довольны.
А посмотришь зачастую в проект на github, а там: «Мигрировали с версии gradle xxx на yyy», через полгода еще раз… потом еще. Большая часть коммитов — такие. И кому нужно такое «развитие» с позволения сказать, которое требует проект раз в полгода переделывать? Чему тут развиваться, если сам проект остался таким же? Система сборки не требует такого, и не должна.
Ктож вас-то заставляет монолитное писать? Кстати, если в проекте нет контейнера — то с модульностью там обычно все еще хуже, чем когда он есть. А все без исключения виденные мной лично попытки заменить Java EE своим велосипедом как правило были намного хуже — впрочем, я это и сегодня живьем наблюдаю. Какой только фигни там не встретишь.
Часто? Я вот видел подход десятка крупнейших банков. Он бывал любой — от «используйте то, что считаете нужным, включая опенсорс» до «ваш выбор Weblogic такой-то версии». Покупной софтины требующей сервера вообще ни видел никогда — обычно сервер просто входит в ее комплект (это IBM BPM к примеру — вебсфера внутри). Покупали вообще мало — значительно больше делают сами. Выбор Java EE всегда был осознанным и своим (хотя и не всегда все с этим были согласны). А все известные попытки написать свой велосипед с транзакциями и JMS на коленке — провалились.
А оно хоть стало лучше по сравнению с предыдущими версиями? Потому что попытки запустить кажется версию 2 на рабочей машине с 8gb и i7 как-то закончились совсем грустно.
Репозиторий maven central сопровождает компания sonatype, кстати, вполне себе коммерческая (продает тот же repository manager, например).
Они сами вполне однозначно высказались по поводу данного инцидента, и я советую их пост просто прочитать.
Насколько я понимаю, ситуация типа той, что была с kik, ровно в таком же виде невозможна (потому что пакеты именуются как домены, и чтобы опубликовать пакет com.kik, нужно подтвердить, что ты владелец домена). И потом у тебя права на эти пакеты просто так не отнимут.
Ну и насчет удаления — его реально нет. И это четкая позиция держателя репозитория — если пакет (версию) опубликовали один раз, от него могут зависеть сколько угодно проектов, и никто не знает, сколько их. Поэтому удалять его, и даже публиковать измененную версию запрещено — если очень хочется, публикуйте новую.
Безалаберность? Да просто нормальные авторы понимают, что такого рода книги никому не нужны (я не говорю обо всех их видах). Их устаревание до момента выхода в свет всем очевидно. Реально живут только книги по продукту, которые пишутся и развиваются в виде wiki сразу, и обновляются постоянно. А печатную форму приобретают просто путем применения другого форматирования.
Ну как бы вам сказать… вот то что вы так пишете, возникло вовсе не само по себе — а в результате обобщения опыта JavaEE. И более того, насколько я помню, JAX WS это часть именно JavaEE как спецификации. То что оно вообще (я тут про все фреймворки, а не только про JAX WS само собой) стало доступно отдельно — это именно результат развития спецификации и множества ее альтернативных реализаций. Причем развития многолетнего.
Если бы. Вы сначала напишете все в виде join из четырех таблиц, а потом придет тот же самый дядя, и скажет вам, что это будет четыре разные базы (хоста). За две недели до релиза. И это реальный случай, между прочим.
А я и не говорю, что я везде прав. Это, если угодно, был намек. что программисты у нас такие, какие есть. И не у нас тоже — подрядчики не лучше, я видел вживую, какого качества код пишут в IBM, лучше бы его развидеть. Набрать где-то лучше — это зачастую большущая проблема. Набрать таких, которые способны реализовать сами контейнер — ну вы сами только что написали, что мало кто понимает, как он работает. Не видите противоречия? )))
Выбрал бы я его сейчас? А вот не факт. Может быть выбрал бы karaf — но при этом нормального JavaEE уровня реализации многих вещей я там не вижу.
А все ваши соображения — они вполне себе разумные и не вызывают отторжения — если выводы не обобщать на все проекты и всех разработчиков. Потому что «без нормальных тестов» — это давно неправда. Где-то с EJB 3 примерно.
Java 7, извините. С весны прошлого года.
ant этого всего почти не умеет (даже с ivy). gradle и maven умеют, но делают по разному, я не могу сказать, что какой-то подход заведомо лучше. Лично для себя я предпочитаю maven, по той простой причине, что формат pom.xml — он читается любым инструментом, на любом языке, gradle же неявно предполагает, что у вас есть сам gradle, и почитать скажем метаданные проекта без него — это целая история (и кстати, в репозиторий обычно кладут все тот же pom).
История о том, что все глухо лежит, пока не разбудят админа, больше всего похожа на байку. Я лично про такое никогда не слышал — просто потому, что таймауты никто не отменял. А я уже с 2000 года на J2EE. Начиная с EJB 2, который реально был так себе. Только это давно неправда.
remote EJB нарушает транзакционность? С каких это пор? Где вы взяли такой фиговый контейнер?
А насчет лучше и проще… ну может в вашем мире так, а я повторюсь, все крупные проекты, которые я видел и которые были сделаны без контейнера (на сегодня это либо JavaEE либо OSGI) — на них смотреть было больно. Именно потому, все все, буквально, что было изобретено на замену штатным средствам JavaEE, все не работало. В одном своем проекте у меня было примерно полсотни мелких компонент, из которых где-то 40 жили в Weblogic, а остальные 10 были standalone приложениями. Так вот, мороки с этими десятью было не в пример больше — при том что по сложности они были несравнимо меньше.
Так что для меня контейнер дает совсем другое — причем простое и очевидно. Модульность — в виде каких-либо стандартных компонент, которе начиная с EJB3 пишутся легко и непринужденно, а до этого делались с помощью спринга, обозримость runtime в целом, когда контейнер предоставляет скажем консоль, откуда можно посмотреть JMX и порулить ими, запустить и остановить компоненты, и прочая. И когда у вас в проекте этих компонент с полсотни — это уже нифига не мелочи. Попробуйте на пару сотен микросервисов просто порты пораспределять без инструмента — и каково оно?
Короче — я не вижу этого вашего «лучше и проще». Может оно и существует где-то (скажем, для высоконагруженных приложений) — а в среднем проекте, где нагрузки особой нет, пользователей скажем тысяч десять (а это, между прочим, масштаб интранета крупнейших банков), из велосипедов получается одно барахло.
А посмотришь зачастую в проект на github, а там: «Мигрировали с версии gradle xxx на yyy», через полгода еще раз… потом еще. Большая часть коммитов — такие. И кому нужно такое «развитие» с позволения сказать, которое требует проект раз в полгода переделывать? Чему тут развиваться, если сам проект остался таким же? Система сборки не требует такого, и не должна.
Они сами вполне однозначно высказались по поводу данного инцидента, и я советую их пост просто прочитать.
Насколько я понимаю, ситуация типа той, что была с kik, ровно в таком же виде невозможна (потому что пакеты именуются как домены, и чтобы опубликовать пакет com.kik, нужно подтвердить, что ты владелец домена). И потом у тебя права на эти пакеты просто так не отнимут.
Ну и насчет удаления — его реально нет. И это четкая позиция держателя репозитория — если пакет (версию) опубликовали один раз, от него могут зависеть сколько угодно проектов, и никто не знает, сколько их. Поэтому удалять его, и даже публиковать измененную версию запрещено — если очень хочется, публикуйте новую.