Чтобы полностью раскрыть все преимущества Kotlin, пересмотрим некоторые подходы, которые мы используем в Java. Многие из них могут быть заменены на лучшие аналоги из Kotlin. Давайте посмотрим на то, как мы можем написать идиоматичный код на Kotlin.

Тема по улучшению взаимодействия машин и человека сейчас актуальна как никогда. Появились технические возможности для перехода от модели «100 кликов» к парадигме «скажи, что ты хочешь». Да, я имею в виду различные боты, которые уже несколько лет разрабатывают все кому не лень. К примеру, многие крупные компании, не только технологические, но и retail, logistics, банки в данный момент ведут активный Research&Design в этой области.

Простой пример, как, например, происходит процесс выбора товаров в каком-либо интернет магазине? Куча списков, категорий, в которых я роюсь и что-то выбираю. It suck's. Или, допустим, заходя в интернет банк, я сталкиваюсь с различными меню, если я хочу сделать перевод, то я должен выбрать соответствующие пункты в меню и ввести кучу данных, если же я хочу посмотреть список транзакций, то опять таки, я должен напрягать как мозг, так и указательный палец. Гораздо проще и удобнее было бы зайти на страницу, и просто сказать: «Я хочу купить литр молока и пол-литра водки», или просто спросить у банка: «Что с деньгами?».

В список профессий, которым грозит вымирание в достаточно близкой перспективе, добавляются: теллеры, операторы call центров, и многие другие. И на простом примере, реализовать который у меня заняло часов 7, я покажу, как можно достаточно просто сделать интеграцию распознавания речи, и выявления сущностей, на примере открытого Wit.Ai (Google Speech API интеграция также включена).

В конце 90-х годов работал в одной организации, которая занималась развитием контактной электрической сети и эксплуатацией питающих энергетических установок (тяговых подстанций), плюс осуществляла мониторинг и управление этого хозяйства с помощью специализированного программно-аппаратного комплекса из нескольких диспетчерских пунктов. Комплекс работал под управлением АСУ ТП на древнем советском железе. Тогда стояла задача перевести этот комплекс под windows, включая разработку графического интерфейса, который бы отображал схематически в виде карты всю сеть и события происходящие на ней и подстанциях. Ну и естественно, предоставлял бы возможность управлять ими.

Введение

Доброго времени суток! Сразу скажу, что программировать я начал недавно и большого опыта у меня нет, поэтому не судите строго, тем более, что материалов на данную тему очень мало. В статье я хочу поделиться своим решением проблемы, которая у меня возникла при создании пошаговой 2D стратегии. Для стратегий привычное дело наличие игрового поля. Но как быть, если у пользователя маленький телефон и всё игровое поле не помещается на экране? Таким вопросом я задался примерно месяц назад, когда у меня ещё ничего не было готово. Сначала я решил как обычно обернуть поле в ScrollView и HorizontalScrollView. И тут начинается собственно проблема. Прокручивать можно было только по одному направлению одновременно, что очень неудобно, тем более для игры. Если вам интересно решение этой проблемы добро пожаловать под кат.

Меня зовут Аркадий, я Android-разработчик в Badoo. В последнее время в нашем блоге много постов про Go, PHP, JS, QA, и я решил разбавить их темами по мобильной разработке. Как раз занимался портированием одного Android-проекта с RxJava 1 на RxJava 2 и читал всё, что можно найти на эту тему в интернете. В частности, доклад Джейка Вортона с конференции GOTO Copenhagen 2016. Мне показалось, что это достойный кандидат на перевод – думаю, многие Android-разработчики задумываются о переходе на RxJava 2, и им интересно, что изменилось по сравнению с первой версией.

Джейк сделал достаточно объёмное введение о реактивном программировании, так что знание RxJava 1 не требуется для понимания статьи. Доклад был подготовлен, когда RxJava2 ещё только готовилась к выпуску (на текущий момент уже выпущена версия 2.1.0).

В предыдущей статье Жирные программы-факторы скорости были набросаны наметки по теме — почему программы "тормозят".

Был выделен фактор памяти, как важный, но не было идей по его тестированию его “жирности” в зависимости от фреймворка. И вот, приняв на праздниках спокойное правильное состояние, я такую идею сгенерировал.

Была написана утилита, которая позволяет измерить время загрузки программы и связанные с этим расходы — дисковый ввод/вывод и потребляемую память. Ссылка в конце статьи.

Некоторые тесты под катом.

Выход Java 9 — новой версии платформы — был отложен. Все это связано с недавними возражениями Red Hat и IBM касательно работы над системой модулей.

Пока идёт горячее обсуждение быть или нет быть jigsaw в java 9 и в каком виде ему быть — не стоит забывать про полезняшки, которые несёт с собой девятка — и одна из них — повышение точности Clock.systemUTC() — JDK-8068730.

Что же было раньше ?

До java 8 был System.currentTimeMillis() и System.nanoTime(), и если первый давал wall clock время, но с миллисекундным разрешением, то второй даёт время с разрешением до наносекунд, но область применения ограничена измерением разности времён, причём в рамках одной jvm — и ни о каком использовании такой временной метки между разными машинами и быть не может.

Поэтому часто велосипедят свои precise timestamp дающие wall clock время с большим разрешением, чем у currentTimeMillis (используя jni со всеми вытекающими) — более подробно про разницу между currentTimeMillis и nanoTime, и про велосипед можно почитать в моём старом посте.

Java 8 заложил очень мощный фундамент — Java Time API. С ним можно сказать пока и joda time, и встроить свой велосипед в java.time.Clock, т.к. штатный SystemClock по своей сути работает поверх System.currentTimeMillis() и не может обеспечить разрешение, лучше, чем миллисекунда.

И вот теперь в игру вступает java 9

Блогеры и авторы, пытающиеся быть на передовой, уже немало писали про проект Amber в Java 10. В этих статьях обязательно упоминается вывод типов локальных переменных, улучшения enum и лямбд, иногда пишут про pattern matching и data-классы. Но при этом незаслуженно обходится стороной JEP 303: Intrinsics for the LDC and INVOKEDYNAMIC Instructions. Возможно, потому что мало кто понимает, к чему это вообще. Хотя любопытно, что именно об этой фиче ребята из NIX_Solutions фантазировали на Хабре год назад.

Широко известно, что в виртуальной машине Java, начиная с версии 7, есть интересная инструкция invokedynamic (она же indy). Про неё многие слышали, однако мало кто знает, что она делает на самом деле. Кто-то знает, что она используется при компиляции лямбда-выражений и ссылок на методы в Java 8. Некоторые слышали, что через неё реализована конкатенация строк в Java 9. Но хотя это полезные применения indy, изначальная цель всё же немного другая: делать динамический вызов, при котором вы можете вызывать разный код в одном и том же месте. Эта возможность не используется ни в лямбдах, ни в конкатенации строк: там поведение всегда генерируется при первом вызове и остаётся постоянным до конца работы программы (всегда используется ConstantCallSite). Давайте посмотрим, что можно сделать ещё.

Для многих переход на Java 9 выглядит как нечто абстрактное. Давайте переведем это в практическую плоскость одним коротким победоносным примером, который привел в своей статье Питер Варгас [1].

RMarkdown, R и ggplot

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

Преамбула

Конференция это прежде всего доклады, и далеко не последнее место занимает то, как оформлены слайды доклада.

Безусловно, есть докладчики, которые могут не смотря ни на что, провести доклад даже без единого слайда, но всё же они как правило хорошо дополняют повествование. Одним достаточно накидать мемасиков в доклад и дело готово, другим обязательно надо вставить код, причём на ассемблере (кто не в курсе ещё — JPoint — это конференция по java), и есть ещё те, кому надо показать графики. Впрочем, встречается и их комбинация.

Пожалуй известные средства для создания слайдов это:

• PowerPoint, и вариации в лице LibreOffice Impress, Apple KeyNote
• облачные вариации с тем же подходом — Google Slides
• LaTeX
• и относительно новый (для меня) RMarkdown

Для создания изоморфных приложений на React обычно используется Node.js в качестве серверной части. Но, если сервер пишется на Java, то не стоит отказываться от изоморфного приложения: в Java входит встроенный javascript движок (Nashorn), который вполне справится с серверным рендерингом HTML с помощью React.

Код приложения, демонстрирующего серверный рендеринг React с сервером на Java, находится на GitHub. В статье буду рассмотрены:

• Сервер на Java в стиле микросервиса на основе Netty и JAX-RS (в реализации Resteasy) для обработки web-запросов, с возможностью запуска в Docker.
• Dependency Injection с использованием библиотеки CDI (в реализации Weld SE).
• Сборка javascript бандла с помощью Webpack 2.
• Настройка редеринга HTML на сервере с помощью React.
• Запуск отладки с поддержкой «горячей» перезагрузки страниц и стилей с использованием Webpack dev server.

При переходе к распределённым системам с большим количеством инстансов сервисов в полный рост встают проблемы их обнаружения (service discovery) и балансировки запросов (load balancing) между ними. Как правило, для их решения используются такие специализированные инструменты как Consul, Eureka или старый добрый Zookeeper, в сочетании с Nginx, HAProxy и некоторым мостом между ними (см. registrator).

Основная проблема в подобном подходе это большое количество интеграций, и, как следствие, точек где что-то может пойти не так. Ведь помимо вышеупомянутых решений наверняка будет использоваться локальный маленький PaaS (например Mesosphere Marathon или Kubernetes). Последние, к слову, уже хранят необходимую конфигурацию об окружении (ведь через них идёт весь деплоймент). И встаёт вопрос, а можем ли мы отказаться от специализированных инструментов для service discovery и переиспользовать тот же Marathon для этой задачи?

Краткий ответ — можем. Если интересно как — читайте дальше.

От переводчика:
Я подготовил для вас адаптированный перевод с небольшими дополнениями и исправлениями. Я сохранил несколько пропагандистский стиль оригинальной статьи, но, сама по себе, информация в ней интересная, поэтому решил, все же, перевести.

Люди часто спрашивают меня:
Зачем мне вообще использовать RxJava или Reactor, если то же самое можно сделать с помощью Streams, CompletableFutures и Optionals?

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

Давайте определим 8 критериев, которые помогут нам понять разницу между этими библиотеками и стандартными возможностями Java:

Если тесты сбоят на ранее протестированном коде, то это явный признак того, что в коде появилась какая-то новая ошибка. Раньше тесты проходили успешно и код был правильный, сейчас тесты сбоят и код работает неправильно. Цель хорошего набора тестов заключается в том, чтобы сделать этот сигнал настолько ясным и чётко адресованным, насколько возможно.

Ненадёжные (flaky), то есть недетерминированные тесты ведут себя иначе. Они могут показать как положительный, так и отрицательный результат на одном и том же коде. Другими словами, сбой теста может означать, а может и не означать появление новой проблемы. И попытка воспроизвести ошибку путём перезапуска теста на той же версии кода может привести или не привести к успешному проходу теста. Мы рассматриваем такие тесты как ненадёжные, и в конце концов они теряют свою ценность. Если изначальная проблема — это недетерминизм в рабочем коде, то игнорирование теста означает игнорирование бага в продакшне.

Ненадёжные тесты в Google

В системе непрерывной интеграции Google работает около 4,2 млн тестов. Из них примерно 63 тыс. показывают непредсказуемый результат в течение недели. Хотя они представляют менее 2% от всех тестов, но всё равно ложатся серьёзным бременем на наших инженеров.

Прим. Переводчика. Статья может быть интересна архитекторам и разработчикам, планирующим построение решения на основе микросервисов, либо ищущим способы оптимизации текущего решения, особенно если работа идет с большими объемами данных. Перевод сделан на основе части 1 и части 2 цикла статей о микросервисах на Apache Ignite. Предполагается общее знакомство с экосистемой Java (Apache Ignite работает также с .NET, C++, а через REST и с другими языками, но примеры в статье будут апеллировать к Java), рекомендуется наличие базового знания Spring.

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

Если вы используете решения на основе микросервисной архитектуры там, где есть высокая нагрузка и необходимо работать с активно растущими массивами данных, скорее всего, вы сталкивались или столкнетесь с проблемами классических подходов:

Всем, кто работал с VK API, давно известно, что доступ к любой работе с аудиозаписями ВКонтакте был закрыт 16 декабря 2016 года, а информация о голосовых сообщениях вообще отсутствует в документации.

_{На примере моего пустого сообщества-песочницы}

Так как же это делается?

Вступление

Привет, хабраюзеры! Решил поведать вам о мини-библиотеке Jerminal. Я сейчас работаю над большим коммерческим проектом на Groovy/Java. Ну и мне пришло задание — написать консольку для приложения. К сожалению, было поставлено условие: никаких сторонних решений, все только свое. Недолго думая, я сел и написал ее. Подробнее — под катом.

Основной принцип программирования гласит: не изобретать велосипед. Но иногда, чтобы понять, что происходит и как использовать инструмент правильно, нам необходимо это делать. Сегодня изобретаем ConcrurrentHashMap.

Сперва нам понадобятся 2 вещи. Начнем с 2х тестов — первый скажет, что у нашей реализации нет data races (на самом деле нам нужно проверить, правилен ли наш тест также путем тестирования заведомо некорректной реализации), второй тест мы будем использовать для тестирования производительности с точки зрения throughput.

Я уже довольно давно занимаюсь проблемами машинного обучения и глубокими архитектурами (нейронные сети), и мне необходимо было сделать мини-презентацию системы, генерирующую временные ряды для эмуляции различных процессов. Поскольку на серьезные темы лучше говорить с юмором, то я решил подобрать какой либо веселый пример, чтобы выступление слушалось с улыбками на лицах. Нам крупно повезло, поскольку мы живем в одно время с великим оратором, чьи речи заставляют сердца людей биться чаще. Я говорю о Дональде Трампе. Поэтому вполне естественно было бы создать систему, которая галлюцинировала говорила бы как Трамп.