Java *

Данная статья в некотором роды выжимка того, что Вы могли бы узнать просмотрев разные видео ролики господина Шипилева, Елизарова, Смирнова. Собственно мы даже собрали для Вас плейлист если Вы захотите пойти «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. Что же ждало слушателей на встрече, можно прочитать далее.

Если кто следит за нашим блогом, наверняка уже знает, что мы проводим хардкорные технические конференции в разных областях программирования (Java, .NET, HolyJS, iOS/Android, тестирование). Конференции эти традиционно проходят в Москве и Петербурге, почему? Потому что в этих городах физически больше разработчиков – это позволяет собирать под одной крышей по 500-1000 единомышленников.



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

Как выглядит идеальная на наш взгляд трансляция? Вот несколько ссылок на свежие трансляции последних конференций:
















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

Вот и наступила осень. Кто-то возвращается в город с центнером яблок в багажнике, кто-то — c норвежским пивом прямиком с JavaZone, а мы подготовили для вас материал, который, надеемся, скоротает дождливые вечера. Мы расскажем о трёх летних встречах JUG.ru. Посему разработчики, вернувшись из отпусков, имеют замечательную возможность запастись чашкой горячего чая, завернуться в плед и посмотреть видео с наших митапов.

Итак, летом у нас было три встречи:
    — Douglas Hawkins из Azul рассказал об особенностях работы JIT-компиляторов в HotSpot JVM;
    — Alvaro Hernandez, разработчик ToroDB, рассказал о том, как Java работает с PostgreSQL;
    — наконец, Евгений Борисов порадовал нас новой порцией загадок на тему Spring.

Тестирование занимает особое место в работе каждого из нас. Это очень важная, сложная, не самая приятная, часто недоведённая до конца, недооценённая часть нашей работы. Поэтому я, как практикующий разработчик и технический руководитель небольшого стартапа, был рад возможности побеседовать с экспертом в этой области и задать ему свои наболевшие вопросы. Почему программисты не работают по TDD? Как правильно решать проблемы, связанные модульным тестированием системы, работающей с базой данных? Как избавиться от «человеческого фактора» и автоматизировать, в конце концов, тестирование пользовательского интерфейса?



В рамках подготовки Joker 2016 вышел пост про легаси, который вызвал бурное обсуждение тестирования в Java, которое мы решили продолжить в интервью с Николаем Алименковым.

Николай — специалист в области разработки на Java уже с 12-летним стажем. Помимо основной рабочей деятельности, он — сооснователь и тренер тренингового центра XP Injection, активный участник и докладчик на международных конференциях. При его участии были организованы IT-конференции Selenium Camp, JEEConf, XP Days Ukraine и IT Brunch. Мы поговорили как о том, что можно улучшить в области тестирования в своей команде «здесь и сейчас», так и о том, к каким технологическим переменам нам следует готовиться в будущем.

— Николай, мой первый вопрос — про самотестируемый код, использующий ассерты внутри самого себя. Твоё отношение к этой практике.

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

Часто ли вы пишите shell скрипт и пакетный файл для запуска своего jvm приложения, а как часто копируете из другого проекта?

17 сентября в Киеве пройдет конференция IT NonStop Java Craft. Ее специальным гостем станет Питер Лоури — основатель Performance Java User’s Group и Java Chronicle open-source library, создатель блога Vanilla Java. В Киеве он выступит с двумя докладами, а накануне выступлений проведет воркшоп, посвященный Java 8. DataArt побеседовал с Питером о настоящем и ближайшем будущем Java-экосистемы, популярности микросервисов и основных проблемах модных технологий.