На митапе Сергей Рублев из DINS расскажет, как они с командой написали легковесную библиотеку с типизированными запросами в doobie-like стиле. Ахтям Сакаев из компании «Метр квадратный» поговорит о Calypso — Scala-библиотеке для удобной работы с BSON. Олег Нижников из Tinkoff.ru рассмотрит паттерн Higher Kinded Data. Участие бесплатное, но нужно зарегистрироваться.
Подробная программа и информация о спикерах — под катом.
В данной заметке мы продолжим говорить о NER компонентах и попытаемся определить условия, в которых нам начинает недоставать функционала стандартных компонентов и стоит задуматься о программировании своих собственных.
В подавляющем большинстве случаев для поиска пользовательских сущностей достаточно найти и настроить какой-либо уже существующий компонент, сконфигурировать или обучить его модель. Лишь иногда, в достаточно специфичных ситуациях, возможностей существующих решений оказывается недостаточным, и нам приходится начинать программировать. Но выделение ресурсов, кодирование, тесты, поддержка - все это стоит затевать лишь когда без всего этого просто не обойтись.
Приглашаем в онлайн-школу DINS: здесь мы научим программировать на Scala и сделаем оффер лучшим студентам. Прием заявок открыт до 16 февраля. Подробности под катом.
По вопросу обработки ошибок уже множество статей написано и все равно возникают вопросы и споры. Я не стану рассматривать все способы и языки, но хотел бы остановится на исключениях в JVM и сравнить их с функциональным подходом (`Try`/`Either`) на примере Scala.
Эта статья так же не про сравнение ФП с ООП – совсем не обязательно бросать одно ради другого. Но посмотреть и сравнить всегда полезно.
Как знают многие разработчики, обработка ошибочных ситуаций - архиважная составляющая любого полноценного кода, претендующего на использование в реальной жизни.
И как следствие, писать обработку ошибок - прямая обязанность любого ответственного программиста. Некоторые считают, что если вы не предусмотрели все варианты поведения - вы не программист, и диплом вам не дадут (если речь о студентах).
Но с другой стороны, обрабатывать ошибки всегда лениво и напряжно. Поэтому существует много инструментов для облегчения этой задачи. Стандартный механизм обработки ошибок в Java - Exceptions. Я не буду сейчас расписывать скучные описания, как бы отвечая на скучные вопросы со многих собеседований. Скажу лишь, что Исключение - это на мой взгляд, неправильный перевод понятия Exception. Я считаю, что исключение, то есть исключительная ситуация - это про другого представителя летающих монстров, java.lang.Error.
А Exception - это не исключение, это часть правила. Это всегда один из возможных исходов. Я бы перевёл этот класс не иначе как Отклонение. В смысле отклонение от прямого курса. Потому как перехватив это отклонение, можно курс выправить и продолжить работу. А Исключение - это для безответственных разработчиков.
Так вот. Давайте теперь перехватывать эти отклонения. Как можно это сделать?
В современной разработке существует тенденция наследовать все Exception от непроверяемых исключений. Это позволяет не заботиться о написании кода обработки ошибок. Я считаю этот подход расхлябанным и безответственным. И сам всегда пропагандирую использование явно заданных и объявленных отклонений с жёсткой обязанностью их обработать, т.е. настаиваю на использовании только проверяемых исключений/отклонений в любом бизнес-коде.
Это вносит неудобства, да. Надо их везде ловить. Как упростить задачу? Обычно советуют тупо оборачивать исключение в java.lang.RuntimeException. Но такой подход чреват тяжёлыми последствиями, когда приложение выходит в релиз и на бой. Я как человек, имеющий ещё и плюсовый бэкграунд, прекрасно знаю, что некоторые ситуации невозможно предугадать даже очень внимательно вглядываясь в код. А потом искать их причины днями, неделями, иногда месяцами. Потому что кто-то в самом начале, в месте возникновения ошибки не объявил о возможности их возникновения.
Моя предыдущая статья была про неявные преобразования и extension-методы. В этой статье обсудим новый способ объявления тайпклассов в Scala 3.
Научившись добавлять внешние методы к произвольным классам, мы хотим пойти еще глубже, а именно научиться приводить произвольные классы к "внешним" интерфейсам, то есть без непосредственного наследования от них. Эту задачу как раз решают тайпклассы.
Это моя вторая статья с обзором изменений в Scala 3. Первая статья была про новый бесскобочный синтаксис.
Одна из наиболее известных фич языка Scala — имплиситы (от англ. implicit — неявный — прим. перев.), механизм, который использовался для нескольких разных целей, например: эмуляция extension-методов (обсудим в этой статье), неявная передача параметров при вызове метода, наложение ограничений на возможный тип и др. Все это — способы абстрагирования контекста.
Для освоения Scala требовалось в том числе научиться грамотно применять механизм имплиситов и связанные с ним идиомы. И это был серьезный вызов для новичков.
В Scala широко используется подход к наделению классов дополнительной функциональностью, называемый type classes. К сожалению в текущей версии scala автоматическая генерация type class затруднена. Она требует либо самостоятельного написания макросов, либо использования сторонних фреймворков для генерации type class.
В Scala 3, которая стремительно движется к релизу, появилась встроенная в язык возможность автоматической генерации type class. В этой статье делается попытка разобраться с использованием этого механизма на примере конкретного type class.
На текущий момент не так много примеров тестов для приложений на основе Spark Structured Streaming. Поэтому в данной статье приводятся базовые примеры тестов с подробным описанием.
Все примеры используют: Apache Spark 3.0.1.
Представляем последнее большое обновление IntelliJ IDEA в этом году. Версию 2020.3 можно скачать с нашего сайта, установить через приложение Toolbox, обновиться прямо в IDE или, если вы пользуетесь Ubuntu, с помощью snap-пакетов.
IntelliJ IDEA 2020.3 несет в себе множество полезных функций: интерактивные подсказки в отладчике, поддержку Git-стейджинга, расширенную поддержку записей и запечатанных классов из Java 15. В новой версии проще работать с окном Endpoints, фреймворками и профилировщиком. Мы также обновили начальный экран, улучшили сортировку вариантов автодополнения на основе машинного обучения и расширили возможности спелл-чекера.
Подробно ознакомиться с новыми функциями вы можете на сайте.
Только что вышло очередное обновление EAP 12 для плагина под названием Big Data Tools, доступного для установки в IntelliJ IDEA Ultimate, PyCharm Professional и DataGrip. Можно установить его через страницу плагина или внутри IDE. Плагин позволяет работать с Zeppelin, загружать файлы в облачные хранилища и проводить мониторинг кластеров Hadoop и Spark.
В этом релизе мы добавили экспериментальную поддержку Python и поиск по ноутбукам Zeppelin. Если вы страдали от каких-то багов, их тоже починено множество. Давайте поговорим об этих изменениях более подробно.
Это первая статья в моей серии статей с обзором изменений в Scala 3.
Давайте начнем с наиболее противоречивых нововведений: опциональных фигурных скобок и
нового синтаксиса для управляющих конструкций.
Опциональные фигурные скобки делают Scala-код больше похожим на Python или Haskell, где для группировки выражений используются отступы. Рассмотрим примеры, взятые из 3-го издания моей книги Programming Scala, которое сейчас готовится к публикации.
Пока индексируется github (спасибо лимиту в 5000 запросов в час), поговорим пока о тестировании парсеров. Обсудим пожелания к процессу разработки грамматик, их тестирования и контроля качества так, что бы не превращаться в существо на картинке.
К нашей новой программе "Apache Spark на Scala для дата-инженеров" и вебинару о курсе, который пройдет 2 декабря, мы подготовили перевод обзорной статьи о Spark 3.0.
Spark 3.0 вышел с целым набором важных улучшений, среди которых: повышение производительности с помощью ADQ, чтение бинарных файлов, улучшенная поддержка SQL и Python, Python 3.0, интеграция с Hadoop 3, поддержка ACID.
В этой статье автор постарался привести примеры использования этих новых функций. Это первый первый материал о функциональности Spark 3.0 и у этой серии статей планируется продолжение.
Время летит. Не успеваешь моргнуть глазом, а уже вышел очередной релиз Java. В соответствии с графиком (по релизу каждые полгода) комьюнити получило в свое распоряжение Java 15, судьба которой — стать фундаментом для Java 17 LTS (выйдет через год).
В Java постоянно вносятся улучшения, многие из которых были реализованы под влиянием других языков JVM и функционального программирования. Сюда можно отнести такие возможности, как лямбды, ограниченный вывод типов локальных переменных (тип var) и switch-выражения. Scala — особенно богатый источник идей, благодаря инновационному сочетанию в ней объектно-ориентированного и функционального программирования.
Предлагаю рассмотреть, как представленные в новом релизе Java 15 (пока в статусе превью финальной версии) возможности соотносятся с конструкциями в Scala. Мы сосредоточимся на особенностях языка, пропустим улучшения в JVM и доработку стандартной библиотеки. Кроме того, нужно отметить, что некоторые из описанных компонентов уже были доступны в более ранних версиях Java (в виде предварительной или бета-версии).
Рано или поздно в нагруженном проекте возникает потребность в какой-то специализированной базе данных, кэше или ином хранилище. Причина такой потребности, как правило, погоня за производительностью, низким временем отклика или эффективностью хранения данных.
В своем докладе я расскажу о нашем опыте разработки и эксплуатации специализированной timeseries БД, в основе которой лежит Apache Kafka.
Прежде чем начать, зацените эту красоту! Это — игра "жизнь" на языке APL:
В прошлой статье о функциональном программировании мы обсудили некоторые концепции ФП (впрочем, довольно вольно). В этой статье я бы хотел продолжить раскрывать суть других понятий, не затронутых в первой статье. Все же ФП не ограничивается одними монадами, хотя о них сегодня тоже поговорим.
Впереди вас ждут скандалы, интриги, расследования, моноиды, трансформеры, линзы и прочие полугруппы с комонадами. Заодно попытаемся разобраться, откуда происходят эти странные названия.
