Владимир Олохтонов, у бизнеса мне не встречались задачи, которые программист самоучка не мог бы осилить. Такие задачи есть разве что у Oracle, Microsoft, Google и т.п. Да и то очень мало.
blanchee, зачем хранить в БД логин и пароль для входа в кастомную админку? В чём проблема проверять право доступа авторизованного пользователя, как в стандартной админке?
Владимир Олохтонов, источник юмора - жизненный опыт. А опыт показывает, что выпускники ВУЗов, даже с красными дипломами, абсолютно бесполезны, если у них не было реального опыта работы в период обучения.
Вася и Петя одновременно начали писать один и тот же продукт.
Вася был «ориентирован на результат» и начал сразу писать говнокод не продумав толком архитектуру.
А Петя месяц разрабатывал архитектуру, месяц делал удобный интуитивный интерфейс, которому позавидывал бы Джони Айв, потом месяц писал тесты, потом два месяца писал сам код и получил идеальное стабильное приложение.
Но Вася выпустил уже через месяц первую версию программы, пусть и не идеальную, пусть с багами, но рабочую, и начал её продавать. Ещё через месяц выпустил вторую версию исправляющие баги первой и добавляющие новые баги. Ещё через месяц на доходы от продаж нанял двух толковых программеров, которые за два месяца перелопатили весь код, согласно пожеланиям пользователей допилили интерфейс и выпустили третью версию программы.
Итого, через пять месяцев у Васи было два работника, куча клиентов и сносно работающее приложение отвечающее желаниям клиентов.
У Пети было вылизанное никому не известное приложение, минус на банковском счёте и ни одного клиента.
В завершение этого выдуманного примера можно сказать, что через полгода Вася купил все наработки Пети, Петю взял в штат тестировщиком, а сам по пьяни разбился на своём новеньком Туареге.
:)
Ваш вопрос можно сократить до "Нужно ли увеличивать свой профессионализм или замкнуть себя в одном языке и технологии?", но в такой постановке вопросом он быть перестаёт. Конечно нужно.
nuclear_kote, майн готт, шедеврально ступил! Ну, в таком случае никаких проблем, можно использовать обычные потоки, можно даже сделать экземпляры Thread бинами и можно использовать спринговый TaskExecutor.
nuclear_kote, это будет уже не спринг. Один процесс слушает сеть и пишет результат в базу. Другой, уже Spring MVC процесс, при запросах из базы читает. Поверьте - это самый надёжный, производительный и простой способ.
nuclear_kote, и что потому нужно делать с полученными пакетами? Складировать в базу для долгосрочного хранения и обработки? Выводить пользователю при следующем запросе? Выводить в реалтайме через удерживаемое открытым соединение websocket?
