
Какой самый стремительный взлет в Лиги наций УЕФА?
С момента запуска Лиги наций УЕФА прошло целых два розыгрыша и уже можно подвести промежуточные результаты)
Мультипарадигмальный язык программирования
Какой самый стремительный взлет в Лиги наций УЕФА?
С момента запуска Лиги наций УЕФА прошло целых два розыгрыша и уже можно подвести промежуточные результаты)
Многие начинающие и не очень Scala разработчики принимают implicits как умеренно полезную возможность. Использование обычно ограничивается передачей ExecutionContext во Future. Другие же избегают неявного и считают возможность вредной.
Но я считаю этот механизм важным преимуществом языка, давайте разберемся почему.
Рассмотрим пример использования Selenium на Scala, отвечая на вопрос "Сколько человек в каждой футбольной сборной имеют более одного гражданства?"
Ref и Deferred являются основными строительными блоками в FP, используемыми параллельно, в манере concurrent. Особенно при использовании c tagless final (неразмеченной конечной) абстракцией, эти два блока, при построении бизнес-логики, могут дать нам и то, и другое: параллельный доступ (concurrent access) и ссылочную прозрачность (referential transparency), и мы можем использовать их для построения более продвинутых структур, таких как counters (счетчики) и state machines (конечные автоматы).
Перед тем, как мы углубимся в Ref и Deferred, нам полезно узнать, что concurrency в Cats строится на Java AtomicReference, и здесь мы и начнем наше путешествие.
Scala 3 — это новая основная версия языка программирования Scala. Это результат многолетних исследований, разработок и сотрудничества между компаниями и организациями, которые координируют развитие Scala с помощью многих других людей и организаций, и которые вкладывают свое свободное время, чтобы сделать это возможным. Эти совместные усилия принесли нам наиболее заметные изменения в языке.
Что мотивировало появление новой версии, которая связана с самой сутью Scala (а именно DOT-вычисления — причина, по которой Scala 3 начиналась как Dotty); в новой версии наблюдается повышение производительности и предсказуемости, что делает код более легким, интересным и безопасным; улучшение инструментария и бинарной совместимости; а также еще более дружелюбное отношение к новичкам.
В этой статье мы выделим некоторые изменения, которые, по нашему мнению, имеют большую ценность для начинающих программистов Scala. Мы также поговорим о процессе миграции и бинарной совместимости. Наконец, в конце мы поделимся нашим мнением об этой новой версии.
На митапе Сергей Рублев из 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 запросов в час), поговорим пока о тестировании парсеров. Обсудим пожелания к процессу разработки грамматик, их тестирования и контроля качества так, что бы не превращаться в существо на картинке.