Очень странный ценник озвучен. Я сам как то подрабатывал на java и в среднем час работы оценивался в 600 рублей. Недавно нанимал python программистов, тоже брали 600 рублей за час. 28к месяц для дизайнера, уж не знаю что такой дизайнер может надизайнить.
Лично мое мнение состоит в том, что Spring Roo не очень удачное решение.
Я сейчас копаю Spring Boot вот это очень классный фреймворк от команды спринга. Он конечно не решает задачи, которые решает Spring Roo, но я очень советую обратить внимание на данный фреймворк.
Меня вот удивляет одно. Вот есть фреймворки, где надо просто отнаследоваться от класса, дописать свой код или конфигурацию. А есть фреймворки, где надо вызвать пару команд и нагенерируется куча непонятного кода. Мне лично нравится первый вариант. Потому что в этом случае я спокойно могу посмотреть и разобраться в коде фреймворка. В куче нагенерированного кода разбираться совершенно нет желания. Поэтому я отказался от использования Spring Roo.
Давайте говорить не в общем NoSQL, а конкретно о MongoDB. Понятие NoSQL все-таки будет пошире. Я очень рад, что в MongoDB есть такой функционал. И мне даже стало интересно, что быстрее будет считать фасеты, MongoDB или Elasticsearch?
Смотрите вот вы отфильтровали товары. У вас есть еще 50 характеристик по которым можно фильтровать эти отфильтрованные товары. Как вы рассчитаете количество товаров для каждой из этих 50 характеристик в уже отфильтрованных товарах? 50 запросов дополнительных пошлете?
Как сказал товарищ выше это задача search engine, а не database engine.
А это разве не самый обычный фасетный поиск, который легко реализуется на основе практически любого поискового движка?
К примеру, как говорили люди выше: elasticsearch
Сейчас в библиотеке hazelcast точно есть очередь.
А какими тулами Вы пользовались при работе с zookeeper?
К примеру, Вы пробовали использовать curator.apache.org/?
Помню был у меня случай с этим говномостром.
Писал очень простое приложение для заказчика. Обычный war. Разрабатывали его под tomcat. Когда заказчик всю работу принял, он ненароком попросил установить приложение ему в прод, где стояла эта шляпа. Два дня я мучался, чтобы приложение заработало. То одно, то второе, то третье.
Сплошные конфликты библиотек, которые не решались тем, что в админке поставить галочки, которые определяют приоритет библиотек.
Получив опыт работы с данной шляпой, я себе сказал, что никогда в жизни более не буду работать с этим монстром…
The main reason not to do this, as Thorbjørn Ravn Andersen says in a comment below, is that you don't wan't to mix 'real, bad NPEs' with NPEs thrown intentionally.
In his famous book, Clean code: a handbook of agile software craftsmanship[3], Robert C. Martin writes the below lines supporting Unchecked Exceptions.
The debate is over. For years Java programmers have debated over the benefits and liabilities of checked exceptions. When checked exceptions were introduced in the first version of Java, they seemed like a great idea. The signature of every method would list all of the exceptions that it could pass to its caller. Moreover, these exceptions were part of the type
of the method. Your code literally wouldn’t compile if the signature didn’t match what your code could do.
At the time, we thought that checked exceptions were a great idea; and yes, they can yield some benefit. However, it is clear now that they aren’t necessary for the production of robust software. C# doesn’t have checked exceptions, and despite valiant attempts, C++ doesn’t either. Neither do Python or Ruby. Yet it is possible to write robust software in all of these languages. Because that is the case, we have to decide—really—whether checked exceptions are worth their price.
Checked exceptions can sometimes be useful if you are writing a critical library: You must catch them. But in general application development the dependency costs outweigh the benefits
Из вашего рассуждения не понятно какие ексепшены где лучше использовать. Статья пустая. В любой книге написано то, что вы написали. В книге CleanCode на эту тему есть хорошее объяснение.
P.S. Не смог вставить ссылку на книгу it-ebooks.info/book/1441/
Я сейчас копаю Spring Boot вот это очень классный фреймворк от команды спринга. Он конечно не решает задачи, которые решает Spring Roo, но я очень советую обратить внимание на данный фреймворк.
Как сказал товарищ выше это задача search engine, а не database engine.
К примеру, как говорили люди выше: elasticsearch
А какими тулами Вы пользовались при работе с zookeeper?
К примеру, Вы пробовали использовать curator.apache.org/?
Писал очень простое приложение для заказчика. Обычный war. Разрабатывали его под tomcat. Когда заказчик всю работу принял, он ненароком попросил установить приложение ему в прод, где стояла эта шляпа. Два дня я мучался, чтобы приложение заработало. То одно, то второе, то третье.
Сплошные конфликты библиотек, которые не решались тем, что в админке поставить галочки, которые определяют приоритет библиотек.
Получив опыт работы с данной шляпой, я себе сказал, что никогда в жизни более не буду работать с этим монстром…
И он абсолютно прав.
The debate is over. For years Java programmers have debated over the benefits and liabilities of checked exceptions. When checked exceptions were introduced in the first version of Java, they seemed like a great idea. The signature of every method would list all of the exceptions that it could pass to its caller. Moreover, these exceptions were part of the type
of the method. Your code literally wouldn’t compile if the signature didn’t match what your code could do.
At the time, we thought that checked exceptions were a great idea; and yes, they can yield some benefit. However, it is clear now that they aren’t necessary for the production of robust software. C# doesn’t have checked exceptions, and despite valiant attempts, C++ doesn’t either. Neither do Python or Ruby. Yet it is possible to write robust software in all of these languages. Because that is the case, we have to decide—really—whether checked exceptions are worth their price.
Checked exceptions can sometimes be useful if you are writing a critical library: You must catch them. But in general application development the dependency costs outweigh the benefits
P.S. Не смог вставить ссылку на книгу it-ebooks.info/book/1441/