Юрий Артамонов jreznot

К сожалению разобрать байт код нельзя, потому что, чтобы его получить, нужно скомпилировать код. А зависимости мы ищем как раз для того, чтобы этот самый код скомпилировать.

Вы читаете мой комментарий или сразу отвечаете? Я спросил только про Build Tool. SBT один из самых противоречивых инструментов сборки, который даже в родном Scala сообществе воспринимается как нечто не в меру странное. Чуть ли не половина разработчиков на Scala используют не его, а Gradle.

А почему бы и не Gradle? Зачем вам там SBT?

И разработчикам нравятся вот эти застенки в виде боксов?

Все GC в Java определяют достижимость объектов от корней кучи. Если объект недостижим — он кандидат на отстрел, циклические ссылки не могут препятствовать отстрелу по определению.

Если нужен custom-интерфейс, то вполне можно делать, Благо компонентов много: https://www.cuba-platform.com/online-demo

А откуда вы вообще взяли, что Lucene и Activiti имеют какие-то проблемы с масштабируемостью? Lucene — де-факто стандарт в своей области, как и Activiti, активно используемый в Alfresco.

Мы используем свежие версии Vaadin 7.6 (в скором времени 7.7), но интерфейсы компонентов и декларативная разметка для экранов у нас своя. Мы не хотим распыляться на несколько UI фреймворков, поскольку мы сами тоже пишем компоненты для UI, кроме того, для custom веб-сайтов мы предлагаем модуль интеграции со Spring MVC и свой generic REST-API.

C WebSocket в 7.6 всё довольно хорошо, сложных проблем ещё ни разу не возникало.

Стандартные библиотеки для интеграции Spring и Vaadin не используем, у нас свой слой интеграции, и Vaadin используется только и исключительно как UI toolkit.

Ну а уж на вопрос про покрытие тестами вы можете ответить сами, юнит тесты лежат прямо в проекте cuba на github. Тестовое покрытие наших премиальных компонентов мы, пожалуй, можем раскрыть только нашим клиентам.

Я думаю поддерживается, но не для всего приложения. Сущности JPA придётся оставить на Java, а вот код сервисов и экранов можно будет писать на Scala. Мы проверим насколько хорошо можно использовать Scala с CUBA, как сделали это для Groovy. Groovy сейчас поддерживается даже в Studio.

> это поддержка пользовательских объектов и их поведения…. Это делает Постгрес невероятно гибким и надежным.

Маркетинговая манипуляция мнением относительно надёжности

А куда сообщать то? Там половину текста бы править ещё, там русский на русский не похож

Я думаю многие компании побояться это делать, ведь тесты открывают большой пласт информации для поиска проблем безопасности

В Scala проблемы с различимостью не замечено

Да, наверное это моя ошибка, считать что, если докладчик из какой-то компании, то доклад заапрувлен и выверен

Могу перефразировать, "с явного одобрения происходяшего компанией". Иначе в описании спикера не стали бы писать, что "человек руководит тем то и тем то важным".

Хм, про Jetbrains могу уверенно сказать, что доклад был под эгидой компании. И многие смотрели доклад, ожидая другой материал, который бы соответсвовал имиджу компании.

В прошлом году было два доклада про Scala. Тот что от Jetbrains был совсем глупый и бесполезный, хотя с зазывающим названием. Зато доклад от Sociohub был приятный, в этом году есть доклад от того же спикера: Страх и ненависть в распределённых системах.

Это точно, Барух — эксперт по управлению зависимостИ, осталось выяснить какой

Объясните, пожалуйста, почему на бумажных книгах 2015 года уже который раз красуется 2016 на самом видном месте. Это просто раздражает.

Из ваших заметок пока видится только один посыл: не критикуйте MySQL. Лучше бы побольше писали про настоящие недостатки, на которые нужно смотреть при сравнении с Postgres.

Ох хо хо! Очень советую вам набежать на CUBA.platform. И Java, и CRUD, и быстро и даже импортозамещение. Да, реклама, но ссылок не даю.

Эх, двести лет уже все ждут понятные NPE в Hotspot

>> Vaadin это Java фреймворк для создания современных высокопроизводительных веб приложений
Это совсем плохое описание Vaadin, высокопроизводительные это не про них, больше подошло бы:

Vaadin — фреймворк для разработки веб-приложений с server-side моделью программирования и состоянием UI на сервере.

У вас что-то guava делает во фреймворках, а в «Добавление новых возможностей в язык Java» откуда-то взялся Guice.

Вы пробовали Gradle? На первый взгляд кажется, что он может решить задачи описанные в статье.

Groovy намного ближе к Java, чем Scala. Использовать для Java проектов SBT я бы не стал. При этом в Gradle отличная поддержка всех трёх языков: Java/Groovy/Scala.

Это много раскиданных файлов вместо одного скрипта на проект в корне.

И вас устраивает количество мусора в проекте? Разные build.sbt, pligins.sbt и отдельная папка project? Уж лучше лаконичный Gradle с одним скриптом build.gradle, чем этот вынос мозга.

Этот выбор был сделан нами очень давно (более 5 лет назад) и с тех пор мы смотрели несколько веб фреймворков — ZK, Smart GWT, и даже JS фреймворки. Но ни разу мы не находили необходимой нам функциональности и гибкости. Наработок по Vaadin у нас очень много и в перспективе мы не планируем от него отказываться.

Мы тестируем пользовательский интерфейс платформы при помощи Selenium, но это действительно требует времени. Дополнительно мы тестируем код компонентов и код UI слоя при помощи тестов с Mock-объектами, когда большая часть инфраструктуры мокается. Но всё же это далеко от хорошего покрытия тестами UI.
У нас всё усугубляется тем, что прикладной UI код исполняется на стороне сервера, но код компонентов исполняется и на стороне браузера. Из-за такого размазывания приходится больше полагаться на Selenium тесты, если тестируем компоненты и сложный UI.
MVP к сожалению нам не подошло, у нас больше компонентный подход к UI.

У нас довольно богатый функционал UI — есть таблицы, деревья, фильтры (задаваемые пользователем в UI и исполняемые в виде преобразованного SQL), много разных полей ввода, поиска. Использование платформы может сильно помочь в проектах с большим количеством форм ввода, таблиц, графиков. Никаких сложностей при создании CRUD в приложениях на платформе мы давно в глаза не видывали.

Наши приложения сильно отличаются от классических Java + Spring MVC, и больше тяготеют к большим десктоп-решениям.

Список основных возможностей
Библиотека визуальных компонентов

Штука очень плохая, ваше устройство ходит в сеть, не спрашивая вас.

Знаете, а я сильно ненавижу гугл за возможность удалять программы удалённо с моего телефона. И вот такой способ блокирования тоже может вредить пользователям, ведь достаточно взлома гугл аккаунта, чтобы доставить реальные физические проблемы с ноутбуком.

Начальник может быть менеджером, а подчинённый — техническим специалистом. И менеджер может не понимать всего в технической области.

Вы не понимаете смысла специализации.

Ну вы уж сделайте поправку на то, что это с одной стороны демонстрационный пример, а с другой — готовый для использования на сервере компонент, с поддержкой биндинга данных и полноценным Java API.

Не писали, хотя стоит им написать, а то у них GWT плагин и Vaadin плагин живут отдельной жизнью.

GWT для Vaadin нет в виде отдельного SDK. Все классы GWT перепакованы в jar файлы Vaadin. А IDEA хочет видеть жарники GWT. Вероятно есть какой-то вариант решения это проблемы, но видимо не простой.

Плюс в Vaadin используется один большой permutation, вместо множества под каждый браузер (<collapse-all-properties/>).

Мы используем 2.7 (он включён в Vaadin 7.3), перекомпиляция быстрая. Мы вообще не очень часто правим GWT код, поскольку у нас стабильный набор серверных компонентов.

К сожалению GWT плагин для Idea требует GWT SDK, а Vaadin использует свою сборку GWT (форк с фиксами). При попытке использования плагина в ClassPath попадают версии исходников из GWT SDK, а некоторым классам Vaadin требуются классы из их GWT сборки.