Scala *

12 июля 2018 года в офисе компании КРОК прошла встреча московского сообщества Java-разработчиков jug.msk.ru, докладчиком на которой был Алексей Зиновьев. Темами встречи были Big Data и машинное обучение (machine learning).

Долгое время я мечтал научиться работать с FPGA, присматривался. Потом купил отладочную плату, написал пару hello world-ов и положил плату в ящик, поскольку было непонятно, что с ней делать. Потом пришла идея: а давайте напишем генератор композитного видеосигнала для древнего ЭЛТ-телевизора. Идея, конечно, забавная, но я же Verilog толком не знаю, а так его ещё и вспоминать придётся, да и не настолько этот генератор мне нужен… И вот недавно захотелось посмотреть в сторону RISC-V софт-процессоров. Нужно с чего-то начать, а код Rocket Chip (это одна из реализаций) написан на Chisel — это такой DSL для Scala. Тут я внезапно вспомнил, что два года профессионально разрабатываю на Scala и понял: время пришло...

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

«Simplicity is prerequisite for reliability» by Edsger Dijkstra

Пролог

Графы — столь наглядная и проста для понимания структура данных, еще со времен Леонарда Эйлера заставляла ломать умы человечества над разнородными задачами, вроде того как можно пройти по всем семи мостам Кёнигсберга, не проходя ни по одному из них дважды или как разъездному посреднику, найти самый выгодный маршрут.

В этом посте мы рассмотрим доступ к API Spark из различных языков программирования в JVM, а также некоторые вопросы производительности при выходе за пределы языка Scala. Даже если вы работаете вне JVM, данный раздел может оказаться полезен, поскольку не-JVM-языки часто зависят от API Java, а не от API Scala.

Работа на других языках программирования далеко не всегда означает необходимость выхода за пределы JVM, и работа в JVM имеет немало преимуществ с точки зрения производительности — в основном вследствие того, что не требуется копировать данные. Хотя для обращения к Spark не из языка Scala не обязательно нужны специальные библиотеки привязки или адаптеры, вызвать код на языке Scala из других языков программирования может быть непросто. Фреймворк Spark поддерживает использование в преобразованиях лямбда-выражений языка Java 8, а у тех, кто применяет более старые версии JDK, есть возможность реализовать соответствующий интерфейс из пакета org.apache.spark.api.java.function. Даже в случаях, когда не требуется копировать данные, у работы на другом языке программирования могут быть небольшие, но важные нюансы, связанные с производительностью.

Часть 2: Решение

И снова здравствуйте! Сегодня я продолжу свой рассказ о том, как мы классифицируем большие объёмы данных на Apache Spark, используя произвольные модели машинного обучения. В первой части статьи мы рассмотрели саму постановку задачи, а также основные проблемы, которые возникают при организации взаимодействия между кластером, на котором хранятся и обрабатываются исходные данные, и внешним сервисом классификации. Во второй части мы рассмотрим один из вариантов решения данной задачи с использованием подхода Reactive Streams и его реализации с использованием библиотеки akka-streams.

Часть 1: Постановка задачи

Привет, Хабр! Я архитектор решений в компании CleverDATA. Сегодня я расскажу про то, как мы классифицируем большие объемы данных с использованием моделей, построенных с применением практически любой доступной библиотеки машинного обучения. В этой серии из двух статей мы рассмотрим следующие вопросы.

• Как представить модель машинного обучения в виде сервиса (Model as a Service)?
• Как физически выполняются задачи распределенной обработки больших объемов данных при помощи Apache Spark?
• Какие проблемы возникают при взаимодействии Apache Spark с внешними сервисами?
• Как при помощи библиотек akka-streams и akka-http, а также подхода Reactive Streams можно организовать эффективное взаимодействие Apache Spark с внешними сервисами?

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

Не знаю, как на вас, а на меня в последнее время производят сильное впечатление статьи про новые Java-технологии — Graal, Truffle и все-все-все. Выглядит так, как будто раньше ты придумал язык, написал интерпретатор, порадовался какой язык хороший и погрустил, какой медленный, написал к нему нативный компилятор и/или JIT, а ведь нужен ещё отладчик… LLVM есть, и на том спасибо. После прочтения этой статьи сложилось (несколько гротескное) впечатление, что после написания интерпретатора специального вида работу можно, в принципе, и завершать. Ощущение, что теперь кнопка "Сделать зашибись" стала доступна и программистам-компиляторщикам. Нет, конечно, JIT-языки медленно стартуют, им нужно время на прогрев. Но, в конце концов, время и квалификация программиста тоже не бесплатные — в каком бы мире информационных технологий мы бы жили, если бы до сих пор писали всё на ассемблере? Нет, может, всё бы, конечно, и летало (это если программист грамотно инструкции разложил), но вот насчёт суммарной сложности активно используемых программ у меня есть некоторые сомнения...

В общем, я прекрасно понимаю, что в дилемме «затраченное программистом время vs идеальность полученного продукта ("ручная работа")» границу можно двигать до скончания веков, поэтому давайте сегодня просто попробуем воспользоваться традиционной библиотекой SQLite без подгрузки нативного кода в чистом виде. Будем использовать уже готовую truffle-реализацию языка для LLVM IR, зовущуюся Sulong.

Протокол Casper — как добиться консенсуса и решить проблему доверия

Так выглядит граф сети доверия в протоколе Casper, который отвечает за надежность данных и вычислений в блокчейн-проекте "RChain". Ядро его разработчиков живёт в Сиэтле, но в кооперативе RChain.coop есть девелоперы из Азии, Африки и Европы. Этот текст основан на посте одного из ведущих разработчиков проекта, Майкла Бёрча (Michael Birch), посвященный консенсус-протоколу Casper.

RChain — распределенная вычислительная блокчейн-платформа. Как ethereum, только на порядок шустрее. В теории, ее можно масштабировать до бесконечности, первые реализации на практике позволяют обрабатывать до 40 тысяч транзакций в секунду. Технические подробности — в документе про архитектуру.

Контракты на платформе RChain написаны на языке rholang, с которым я бы хотел познакомить аудиторию хабра. Попробовать написать и выполнить программы на этом языке можно либо скачав и запустив Rchain-ноду через докер, либо воспользовавшись интерпретатором на сайте.

В последнее время у меня было несколько разговоров с друзьями из Java мира об их опыте использования Scala. Большинство использовали Scala, как улучшенную Java и, в итоге, были разочарованы. Основная критика была направлена но то, что Scala слишком мощный язык с высоким уровнем свободы, где одно и тоже можно реализовать различными способами. Ну и вишенкой на торте недовольства являются, конечно же, implicit'ы. Я соглашусь, что implicit'ы одна из самых спорных фич языка, особенно для новичков. Само название «неявные», как бы намекает. В неопытных руках implicit'ы могут стать причиной плохого дизайна приложения и множества ошибок. Я думаю каждый, работающий со Scala, хотя бы раз сталкивался с ошибками разрешения ипмлиситных зависимостей и первые мысли были что делать? куда смотреть? как решить проблему? В результате приходилось гуглить или даже читать документацию к библиотеке, если она есть, конечно же. Обычно решение находится импортом необходимых зависимостей и проблема забывается до следующего раза.

Привет, Хабр!

Сегодня мы вернемся к одной из тем, затрагиваемых в нашей замечательной книге "Реактивные шаблоны проектирования". Речь пойдет об Akka Streams и потоковой передаче данных в целом — в книге Роланда Куна этим вопросам посвящены главы 10 и 15-17.

* Michael G. Noll — активный контрибьютор в Open Source проекты, в том числе в Apache Kafka и Apache Storm.

Статья будет полезна в первую очередь тем, кто только знакомится с Apache Kafka и/или потоковой обработкой [Stream Processing].

В этой статье, возможно, в первой из мини-серии, я хочу объяснить концепции Стримов [Streams] и Таблиц [Tables] в потоковой обработке и, в частности, в Apache Kafka. Надеюсь, у вас появится лучшее теоретическое представление и идеи, которые помогут вам решать ваши текущие и будущие задачи лучше и/или быстрее.

Содержание:

* Мотивация
* Стримы и Таблицы простым языком
* Иллюстрированные примеры
* Стримы и Таблицы в Kafka простым языком
* Пристальный взгляд на Kafka Streams, KSQL и аналоги в Scala
* Таблицы стоят на плечах гигантов (на стримах)
* Turning the Database Inside-Out
* Заключение

Всем привет! Новый год, новый Spark, новый Moscow Spark! Мы стартуем новый сезон нашего замечательного мероприятия 19 апреля на Мансарде Rambler&Co. Фреймворк не стоит на месте и мы тоже, в этот раз представим новый сайт сообщества и опробуем формат со звездой из-за рубежа.

Привет, Хабр!

Мы открыли регистрацию на 48-часовой блокчейн-хакатон Unblock и с удовольствием приглашаем участвовать разработчиков и аналитиков. Уровень квалификации не важен, хакатон – открытый, участие – бесплатное. Желание с головой окунуться в блокчейн-разработку приветствуется.

Недели две назад InfoQ напомнил, что официальная поддержка Java 9 заканчивается… в Марте 2018г. (т.е. через 20 дней :)

Вот cсылка на официальный EOL от Oracle, в которой в разделе "Java SE Public Updates" черным по английскому говорится, что Java 9 будет поддерживаться до Марта 2018, а Java 8 — до Января 2019 (или позже) и Декабря 2020 (или позже).

Scala — это изумительный язык программирования, которым я наслаждался года 4 назад. Я, наверное, был его фанатом: покупал книги и курсы на Coursera, использовал в pet- и продуктивных проектах et cetera, et cetera, et cetera.

Scala открыл для меня увлекательный мир функционального программирования, вернул во времена студенчества со «сферическими задачами в вакууме» от Martin'a Odersky…

Но вот он уже года два как Scala для меня мертва. Виной этому…

Привет, Хабр!

Это вводная статья про то, как следует делать тесты производительности на JVM языках (java, kotlin, scala и тд.). Она полезна для случая, когда требуется в цифрах показать изменение производительности от использования определенного алгоритма.

Все примеры приведены на языке kotlin и для системы сборки gradle. Исходный код проекта доступен на github.

Код этого поста, как и сам пост, выложен на github.

До недавнего времени регулярные выражения казались мне какой-то магией. Я никак не мог понять, как можно определить, соответствует ли строка заданному регулярному выражению. А теперь я это понял! Ниже представлена реализация простого движка регулярных выражений менее чем в 200 строках кода.

Часть 1: Парсинг

Спецификация

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

• . — соответствие любому символу
• | — соответствие abc или cde
• + — соответствие одному или более предыдущего паттерна
• * — соответствие 0 или более предыдущего паттерна
• ( и ) — для группировки

Хотя набор опций невелик, с его помощью можно создать интересные regex-ы, например, m (t|n| ) | b позволяющий найти субтитры к Star Wars без субтитров к Star Trek, или (..)* для нахождения множества всех строк чётной длины.

План атаки

Мы будем анализировать регулярные выражения в три этапа:

1. Парсинг (синтаксический анализ) регулярного выражения в синтаксическое дерево
2. Преобразование синтаксического дерева в конечный автомат
3. Анализ конечного автомата для нашей строки

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

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

Пятого декабря в Санкт-Петербурге прошёл третий митап Scala разработчиков. Юзер-группа встречается раз в 2-3 месяца, в гостях у какой-либо из компаний — активных участников сообщества, использующих язык Scala или смежные ему технологии. На этот раз, площадкой проведения был выбран офис компании JetBrains на Васильевском острове. В нём ведёт свою деятельность команда разработчиков Scala plugin для сред IntelliJ IDEA и Android Studio.

В программе митапа были три выступления наших коллег:

1. Андрей Сугак (JetBrains) рассказал о результатах своей дипломной работы: инструменте Мутационного тестирования проектов на языке Scala;
2. Илья Кириллов (СПБГУ) представил недавно появившийся build tool CBT;
3. Сергей Рублев (eLama) дал ряд практических примеров использования библиотеки Slick.

Подробности выступлений и видеоматериалы под катом…