Юрий Ярош: Думаю я успешно ответил на вопрос "Есть ли жизнь после Java ?" или "не все энтерпрайсы одинаково полезны". Уже успел полностью отказаться от J2EE стека из-за необычайной слоупочности и диких overhead'ов.
Олег: для прикладных приложений выхлоп получается больше (меньше строчек - больше толку), но нужно уметь использовать repl и довольно редко выполнять инкрементальную компиляцию для TDD. Вот groovy наоборот шустрее компилируется и repl опционален - можно спокойно пересобирать всё и прогонять тесты при любом изменении, но grails в работе в раз 10 медленнее чем Play.
Если есть желание ити в ванильную Java - это можно спокойно уходить в Play + Jooq и не заморачиваться. Можно использовать Ebean если есть очень большое желание по'JPA'шничать, да и Vaadin там прикручивается довольно просто.
В принципе так же можно пробросить контекст сервлета в vert.x, если есть желание гонять на Java + Netty и иметь интеграцию с другими языками типа Groovy / Scala / JS. Так как оверхед от использования Scala + Netty в Play2 довольно большой.
murrometz: мне сложно сказать "почему", могу лишь судить по существующим бэнчмаркам (когда-то проскакивали на хабре) и предположить что там где-то фигурирует фильтр Блума и какая-то реализация префиксного дерева. В общем так принято считать со времён второго фаэрфокса :| и это стало одной из причин популяризации БЭМ в Яндексе в далёком ~2008ом.
jonasas Быстрее всего, неправильно выбран формат результирующих файлов и/или неправильно построена задача - принимать данные оно будет, но естественно результаты будут в виде мусора для Cassandra. Вот пример задачи https://svn.apache.org/repos/asf/cassandra/trunk/e...
А вообще...
Hadoop сейчас довольно редко используется в серьёзных проектах из-за кучи оверхедов и проблем поддержки - нужно обязательно привязываться к какому-то вендору, у меня в проектах были почти все и мы остановились на IBM. Все остальные конторы, которые не идут подобным путём - просто не используют Hadoop стэк и Zookeaper в частности (Netflix, Spotify). В основном это поделки в стиле
Kafka -> Hbase -> Storm -> Spark -> (опционально) Storm -> Hbase -> Phoenix -> Hibernate + MVC что-то там.
Сергей Протько: не помню по поводу endpoint'ов, вроде там для сервера тоже где-то что-то проскакивало. По крайней мере у меня пару лет назад люди писали свои шаблоны и для endpoint'ов и для всех клиентов.
По поводу endpoint'ов как раз таки лучше генерить обрабатывать запросы через 6-7 шаблонных контроллеров с возможностью переопределения различных обработчиков типа beforeValidation(Model, List, AsyncResultHandler) etc, и документацию хранить в предварительно сгенерянных файликах под apidoc / swagger, либо сразу в базе со специальным endpoint'ом и отдельной схемой.
В общем нужно делать так что бы был 1 CRUD контроллер на много табличек БД, с возможностью переопределения частных случаев для каждой сущности. Материализованные и промежуточные представления вместе с различными функциями агрегации и их индексами - отдельная тема.
Ok, может напишите причину по которой vk закрыл свои xmpp сервера ?
Яндекс в свое время выбрал erlang. Яндекс выбирает всё что работает и то с чем могут работать люди, но это отнюдь не означает что подобные решения оптимальны - так было с питоном который поменяли на golang, и так было с erlang'ом с которого плавно слезли на ванильную Java и допиленный Netty.
Андрей КLeoCcoder на самом деле очень и очень плохая идея так как вы не мерите накладные расходы на коммуникацию, и не представляете сколько у XMPP совсем бесполезной нагрузки.
Ололёша Ололоев: да... если только вспомнить количество пространственных структур для индексации, например в задачах поиска и классификации по признаком - да... очень мало. Особенно весело то что о большинстве из них в классической литературе типа Кормена / Кнута очень мало упоминаний.
YARUSprog: :| сейчас без вменяемых навыков фронтэнд-разработки бэкенд не построить. Конкретно в случае фриланса - проще брать качеством, скоростью работы и актуальностью технологий, по сему ещё нужно освоить TDD/BDD и понимать как обычно проходит QA в больших проектах.
Div100: сейчас популярна реактивность, всякие RxJava и прочее около CQRS-ES'ное барахло которое к MVC отношения не имеет. Соответственно все MVC фреймворки морально устарели ^-^
Леша Киселев: ноды падали по разным причинам: начиная от утечек памяти, и заканчивая проблемами синхронизации - на одной ноде было по 64Гб оперативки и ~2Тб данных. Проблемы со старту решались экстенсивным путём под предлогом "железо дешевле", в итоге пришлось писать кастомные граф-ориентированные индексы и MVP-tree based индексы для PostgreSQL с довольно большой допилкой его полнотекстового движка, хотя под OpenSource'ом это так и не опубликовалось - контора развалилась :)
ruboss: elasticsearch очень-очень плохо масштабируется. Сам возился с кластером с 16ти машин, и как одна из нод падает каждую неделю по 2-3 раза. Лучше сразу брать Solr и реализовывать нужный функционал в рамках приложения.