Java *

Незаметно пролетели почти три года с момента публикации первой статьи о платформе на Хабре. За это время многое изменилось: мы вышли на международный рынок, перешли к open source лицензии, обновили стек технологий и внесли множество улучшений во фреймворк и средства разработки. Поэтому вместо длинного списка изменений мы решили опубликовать ещё одну обзорную статью о платформе CUBA, которая, я надеюсь, будет интересна разработчикам кровавого энтерпрайза корпоративных информационных систем — как ещё не знакомым с платформой, так и тем, кто уже что-то слышал о ней.

Итак, под катом вы узнаете:

• Что представляет из себя платформа CUBA и какова её архитектура
• Какие решения эффективнее всего разрабатывать на CUBA
• Как платформа помогает сэкономить время разработки корпоративных систем
• Какое окружение необходимо для развертывания CUBA-приложений
• Как мигрировать устаревшую систему на CUBA
• Под какой лицензией распространяется платформа
• Как организована поддержка разработчиков

Рискну предположить, что среднестатистический читатель этой статьи с продуктом Apache Ignite не знаком. Хотя, возможно, слышал или даже читал статью на Хабре, в которой описывается один из возможных сценариев использования этого продукта. О принудительном использовании Ignite в качесте L2 кэша для Activiti я писал недавно. Возможно, узнав о том, что это написанный на Java open source продукт, позиционирующий себя как «высокопроизводительная, интегрированная и распределённая in-memory платформа для вычисления и обработки больших объёмов данных в реальном времени», обладающая, помимо прочего возможностью автоматического деплоймента вашего проекта на все ноды сложной топологии, вам захочется с ним познакомиться. Испытав такое желание, вы обнаружите, что Ignite документирован не то, чтобы совсем плохо, но и не очень хорошо. Есть туториал, кое-какой javadoc, но полного и целостного впечатления от ознакомления с этими источниками не возникает. В настоящей статье я попытаюсь восполнить этот пробел на основе собственного опыта познания Ignite, полученного преимущественно путём дебага. Возможно, в своих выводах и впечатлениях я буду не всегда прав, но таковы издержки метода. От читателя и тех, кто захочет повторить мой путь, требуется не так много, а именно знание Java 8 core, multithreading и Spring core.

В статье будет рассмотрен и препарирован пример класса «Hello World!» с использованием данной технологии.

Под катом будет изложена реализация языка простых арифметических выражений с let конструкцией. Чтение будет интересно для людей, не знакомых с языком kotlin или только начинающих свой путь в функциональном программировании.

variable("hello") + variable("habr") * 2016 where ("hello" to 1) and ("habr" to 2)

В статье читатель познакомится с такими конструкциями Kotlin, как extensions function, pattern matching, operator overriding, infix functions и некоторыми принципами функционального программирования. Написание парсера не входит в тему статьи, поэтому наш язык будем реализовывать внутри языка kotlin, подобно языкам скриптов систем сборки по отношению к скриптовым языкам, на которые первые написаны (grodle: groovy). Материал подается достаточно подробно. Желательно знание Java.

Разработчики программного обеспечения пользуются огромным спросом в настоящее время. В некоторых компаниях даже стажеры-программисты получают высокую зарплату. ИТ-компании борются друг с другом за талантливые кадры.

А кадры, в свою очередь борются за место под солнцем. Успех тех и других будет зависеть от того, насколько хорошо у них получается держать руку на пульсе, быть в тренде, использовать перспективные технологии и языки программирования. Чтобы понять, на что ориентироваться и в каком направлении идти, разработчики ПО и их работодатели изучают различные исследования и рейтинги популярности – будь то бизнес-модели или те же технологии и языки программирования.

Однако некоторые игроки ИТ-рынка оказались предприимчивыми и создали проекты, посвященные ранжированию и трендам. К примеру, на этой неделе GitHub опубликовал собственный рейтинг 15 самых популярных языков программирования. Конечно же, популярность определялась по количеству pull-запросов на GitHub за последний год.

Часто так бывает, что есть хорошая библиотека, а чего-то в ней не хватает, каких-нибудь перламутровых пуговиц. Так и мне с Activiti, довольно популярным движком бизнес-процесcов с поддержкой BPMN 2.0, ценным своей Java-нативностью. Не вдаваясь в подробности внутреннего устройства этого продукта с открытым исходным кодом, достаточно очевидно, что в своей работе он использует разнообразные данные: метаданные определений бизнес-процессов, данные экземпляров и исторические данные. Для их хранения Activiti использует СУБД, позволяя выбрать из DB2, H2, Oracle, MySQL, MS SQL и PostgreSQL. Этот движок весьма неплох, и используется не только для маленьких поделок. Возможно, вопрос о поддержке кэширования обращений к БД в этом продукте возник не только у меня. Как минимум единожды он задавался разработчикам, которые на него ответили в том смысле, что метаданные кэшируются, а для остальных данных большого смысла в этом нет и это не просто. В принципе, про отсутствие большого смысла согласиться можно — данные конкретного экземпляра или его исторические данные с небольшой вероятностью могут повторно понадобиться. Но сценарий, когда такое всё-таки случится, тоже возможен. Например, если у нас кластер серверов Activiti с общей базой. В общем, человек с пытливым умом вполне может захотеть иметь приличный кэш в Activiti. Например, использовать в этом качестве Apache Ignite.

Под катом пример решения этой проблемы, код выложен на GitHub.

Данная статья в некотором роды выжимка того, что Вы могли бы узнать просмотрев разные видео ролики господина Шипилева, Елизарова, Смирнова. Собственно мы даже собрали для Вас плейлист если Вы захотите пойти «the hard way». В статье я лишь попробую Вам передать некоторые основные мысли/идеи, которые при желании Вы сможете намного более глубоко изучить в первоисточниках.

Итак, давайте теперь перейдем к собственно сабжу. Еще лет пять назад можно было не сильно «парясь» выдавать на-гора однопоточные программы, которые с трудом запускались на топовом железе и знать, что через год-два этот кусочек “программки” (простите за аллегорию) начнет работать нормально. Сегодня подобный «бесплатный обед» закончился.


На картинке четко видно, что количество транзисторов все еще растет, но с точки зрения частот мы практически достигли потолка. «Кривизну» рук разработчиков уже трудно компенсировать тем, что через год железо станет работать в два раза быстрее. Хотя не все так печально, процессоры пока еще растут, только с точки зрения количество ядер. Как следствие, для того чтобы «программка», написанная криворуким орком, смогла хоть как-то нормально работать на новом железе, нужно чтобы она нормально работала в многопроцессорной среде. А производительность была напрямую связана с количеством ядер на железе. Вот собственно от том, а что же такое «нормально работала многопроцессорной среде» мы и поговорим далее.

Сегодня хочу рассказать вам об open source проекте под названием Bagri. Bagri — это распределенная база данных документов (document database), или как сейчас модно говорить NoSQL база данных, написанная на Java и спроектированная с учетом требований, в основном используемых в корпоративном секторе, таких как высокая готовность, отказоустойчивость, масштабируемость и поддержка транзакционности.

Когда имеет смысл использовать Bagri

Систему хорошо использовать в первую очередь в тех случаях, когда документооборот основан на XML. Это финансы, логистика, страхование, медицина, и другие индустрии где формат документов, которыми обмениваются участники, строго определён корпоративными схемами XSD. Система позволяет не парсить каждый входящий документ, а класть его в базу как есть, а потом эффективно выполнять любые запросы над хранимыми документами используя мощный инструментарий XQuery 3.1.

Bagri построена поверх продуктов реализующих распределенный кэш, таких как Hazelcast, Coherence, Infinispan и других подобных систем. Именно за счет возможностей распределенного кэша Bagri поддерживает требования корпоративного сектора прямо из коробки. Распределенный кэш используется системой не только как хранилище данных, но и как распределенная система обработки этих данных, что позволяет эффективно и быстро обрабатывать любые большие объемы слабо структурированных данных. Транзакционность в системе решена с помощью алгоритма реализующего multi-version concurrency control

Когда язык программирования используют миллионы человек, кажется, что о нём должно быть предостаточно сайтов, в том числе русскоязычных. Однако, если набрать в поисковике «новости Java», результаты оказываются примерно такими:



Сайты с помощью начинающим в рунете есть (например, JavaRush) — а вот с актуальной информацией для тех, кто уже вовсю работает и хочет держать руку на пульсе, всё гораздо печальнее. Понятно, что большинство опытных Java-разработчиков вполне способно читать новости на английском, но всё равно родной язык понимается быстрее и проще.

Поэтому, во-первых, мы сейчас перезапустили сайт JUG.ru, чтобы исправить это. А во-вторых, раз русскоязычные регулярно обновляемые ресурсы в дефиците, вспомнили, какие есть англоязычные, и делимся результатами с Хабром. Разумеется, в текст вошло далеко не всё возможное, и будем только рады дополнениям в комментариях.

Два года назад в OpenJDK был создан новый проект под кодовым названием «Panama». Основным направлением исследований анонсировалось создание нового интерфейса для работы с платформозависимыми библиотеками и данными вне Java heap’а (off-heap). Но цели проекта шире: исследование механизмов взаимодействия JVM и «внешнего» (не-Java) API.

Владимир Иванов iwanowww — ведущий инженер Oracle, работает в группе разработки виртуальной Java-машины HotSpot. Специализируется на JIT-компиляции и поддержке альтернативных языков на платформе Java. Владимир пришел в Sun Microsystems (приобретена Oracle в 2010) в 2005 году и с того момента поучаствовал в большом количестве проектов, связанных с Java (HotSpot JVM, RTSJ, JavaFX).

JNI 2.0?

— Большая часть проекта Panama — это работа с native библиотеками из Java кода. Как это можно делать сейчас?

— Работать с native кодом в Java можно было всегда. Native методы были еще в первой версии Java, а стандартный интерфейс JNI появился уже в версии 1.1. Но время идет, платформа развивается, требования меняются и, смотря на JNI сейчас, есть понимание, что можно организовать работу с native библиотеками удобнее и эффективнее.

В среде разработчиков часто бытует мнение, что протокол сериализации protobuf и его реализация — это особая, выдающаяся технология, способная решить все реальные и потенциальные проблемы с производительность одним фактом своего применения в проекте. Возможно на такое восприятие влияет простота применения этой технологии и авторитет самой компании Google.

К сожалению, на одном из проектов мне пришлось вплотную столкнуться с некоторыми особенностями, которые никак не упоминаются в рекламной документации, однако сильно влияют на технические характеристики проекта.

С самого появления Gradle существовало 2 способа разбить свою сборку на компоненты: через бинарные зависимости и с помощью многопроектной сборки. Каждый из этих способов имеет свои плюсы и минусы. В случае с бинарными зависимостями возникает необходимость в публикации артефактов, что усложняет сборку. В случае использования многопроектной сборки становится
сложнее изолировать компоненты друг от друга.

Композитные сборки

В готовящейся к релизу версии 3.1 в Gradle появляется новый поход к организации сборок, состоящих из нескольких компонентов: композитные сборки (ориг. Composite Builds).

Композитные сборки позволяют:

• Быстро подложить исправленную версию исходников библиотеки в другой проект без необходимости собирать её, опубликовывать и править сборку.
• Делить большие проекты на несколько небольших, изолированных сборок, над каждой из которых можно работать как по отдельности, так и одновременно.
• Отделить разработку плагина для системы сборки от проекта, его использующего (аналог buildSrc)

Дискуссия вокруг Scala не стихает уже много лет, разворачиваясь в основном на поле противостояния с Java. Действительно, несмотря на общую платформу, языки разные.

Аргументы за Scala известны:

1. Scala лаконичная;
2. Scala функциональная;
3. Scala крутая и современная;

В ответ на то, что Scala медленно загибается, Мартин Одерски заявил следующее: «В 2015-м было затишье, но вот в 2016-м развитие Scala должно ускориться».

В этом посте я не буду глубоко погружаться в техническую дискуссию, есть множество специалистов, которые сделают это лучше меня. Сегодня мы поговорим о том, нужна ли Scala разработчику для саморазвития, для этого хочу предложить вам перевод статьи Matthew Casperson.

Ну и в конце дам пару ссылок на популярные статьи по теме за последние несколько лет, если вдруг вы какие-то из них пропустили.

Вот уже больше 16 лет JetBrains успешно занимается созданием профессиональных инструментов для программистов.

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

Сегодня мы хотим пригласить вас на мини-конференцию, JetBrains Night Moscow, которая состоится 29 сентября (четверг) в гостинице «Novotel Москва Сити». Цель данного мероприятия — пообщаться вживую. Мы расскажем о некоторых наших продуктах, о том что мы делаем, как и почему.

UPD: тут была ссылка на регистрацию, но теперь она недоступна, мероприятие уже прошло, скоро будет доступно видео, о чем мы отдельно напишем и тут тоже ссылку на него сделаем. Спасибо всем, кто пришел!

UPD 2: а вот и видео.

До встречи!
Команда JetBrains

Одним из широко освещаемых свойств фреймворка java.NIO является неблокируемость, что означает спо­соб­ность к параллельному выполнению операций ввода-вывода и вычислений. Если приложение, запросившее чтение файла, имеет вычислительную задачу, которую можно обработать до получения данных из файла, то становится возможным одновременное выполнение этих операций. В случае отложенной записи, возможностей для параллелизма еще больше, так как при записи, в отличие от чтения, приложение не ожидает поступления данных.

Два с половиной года назад я опубликовал статью Пишем, собираем и запускаем HelloWorld для Android в блокноте. Она стала пользоваться огромной популярностью и набрала около 80 000 просмотров. С появлением новых инструментов, таких как Jack ToolChain, возникла необходимость переиздания и обновления статьи.

Когда я начал изучать Android, захотелось полностью написать и скомпилировать Android-приложение вручную — без использования IDE. Однако эта задача оказалась непростой и заняла у меня довольно много времени. Но как оказалось — такой подход принёс большую пользу и прояснил многие тонкости, которые скрывают IDE.

Используя только блокнот, мы напишем совсем маленькое учебное Android-приложение. А затем скомпилируем его, соберём и запустим на устройстве — и всё через командную строку. Заинтересовало? Тогда прошу.

Apache Spark – универсальный инструмент для процессинга больших данных, с которым можно писать в Hadoop с различных СУБД, стримить всякие источники в реальном времени, параллельно делать с данными какую-нибудь сложную обработку, и все это не при помощи каких-то батчей, скриптов и SQL-запросов, а при помощи функционального подхода.


Про Spark ходит несколько мифов:

• Spark’y нужен Hadoop: не нужен!
• Spark’у нужна Scala: не обязательно!

Почему? Смотрите под катом.

Поздравляю всех трансляторов человеческого языка в машинный с их профессиональным днем, желаю вам меньше багов и больше-либо-равно классных идей! А в качестве идейного подарка со своей стороны предлагаю решение одной красивой задачи — написание кода, который на выходе выдаёт свой собственный текст, является валидным для интерпретаторов и компиляторов разных языков, и при этом правильно исполняется при реверсе исходников.

Не так давно я узнал о коде, который может одновременно интерпретироваться в PHP и компилироваться в Java: PhpJava.java. Как оказалось, эта идея не нова: код, валидный сразу для нескольких компиляторов или интерпретаторов, называется полиглотом (polyglot). Такой код возможно писать из-за особенностей обработки строк и комментариев в различных интерпретаторах или компиляторах.

У статических методов есть одна мощная, но и в то же время весьма нежелательная особенность: их можно вызвать из любого места в коде, не особо имея возможность регламентировать порядок их вызова. Зачастую такой контроль очень важен, но иногда порядок не имеет очень большого смысла. Например, осуществлять проверки в юнит-тестах часто можно не в очень строгом порядке. И чтобы гарантировать, что в тестируемом юните выполенены все проверки, в Mockito существует всё тот же статический метод verifyNoMoreInteractions(...). Иногда можно по ошибке вызвать такой метод ещё до последнего verify(...) и потом с огорчением наблюдать "красный" тест. Но что если переложить заботу о порядке выполнения проверок на сам компилятор?

В среду, 14 сентября, в 20:00 в офисе компании SEMrush состоится встреча JUG.ru с Дмитрием Александровым, экспертом по Java EE, Spring и JavaScript. Тема встречи: Nashorn — легкий движок JavaScript на JVM.

В данной сессии мы познакомимся с проектом Nashorn — легким движком JavaScript на JVM. Мы пройдем от простого к сложному: узнаем, как и зачем могут сосуществовать Java и JavaScript. Посмотрим, как вызывать JavaScript из Java и наоборот. Научимся работать в консоли jjs, или как писать (и главное дебажить) скрипты для ОС независимые от ОС при наличии JDK. Посмотрим, как можно применить JavaScript-библиотеки в Java-проектах. Рассмотрим, как можно придать динамизм нашим программам с помощью скриптинга на JS.

Я календарь переверну
И снова третье сентября
И вновь восьмое сентября

8 сентября 2016 года прошла встреча jug.msk.ru, собравшая, возможно, максимальное число участников. Гостями были Барух Садогурский и Кирилл Толкачёв, темой их доклада — DevOps. Что же ждало слушателей на встрече, можно прочитать далее.