Scala *

И почему shutdown требует отдельной статьи, а не вызова метода stop

Ну начну с того, что за метод stop такой.

Из документации, существует 2 метода которые собственно отвечают за остановку Structured stream.
query.stop() // Остановить запрос(stream)query.awaitTermination() // заблокировать пока запрос(stream) не прекратиться по причине вызова stop() или ошибки

Уже только по наличие 2ух методов мы может догадаться что метод stop() асинхронный. Что лично меня навело на мысль, что ни какой проблемы нет и graceful shutdown иметься из коробки.

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

Останавливает выполнение этого запроса если он активен. Вызов блокируется до того как прекратиться выполнение query execution threads или по timeout(время не не выйдет, время задается в конфигурации).

И вот тут опытный Java/Scala разработчик по идее должен был напрячься.

Какой то Thread, уж больно напоминающий java thread по названию, прекратиться по сигналу. Да и в добавок к этому еще один, дополнительный, метод который ждет завершения. Это же thread.interupt() скажите вы, и будете правы - так что ни про какой graceful вообще речь идти не может.

Когда-то давно, в 2015 году, я опубликовал на Хабре статью, если вкратце "Как я на коленке сделал свое 1С:Предприятие, с блек-джеком и шлюхами".

Но это была, во-первых, двухзвенка, а во-вторых, потребовала от меня столько лапшекода, что после кодирования я надолго погрузился в депрессию. Теперь е я готов представить вам вариант производственного процесса, который не отпугнет перебежчика с 1С на Java.

Пригодна ли Java (Scala) и ее библиотеки для задач вывода 3D и анимации? Я попробовал это выяснить на примере библиотеки org.fxyz3d и хотел бы поделиться самой программой и выводам по итогам ее запуска.

Сегодня поговорим о еще одном функторе — инвариантном (Invariant Functor). Уже было несколько постов о ковариантных функторах (называемых просто "функторами") и контравариантных функторах. Если концепция ковариантных и контравариантных функторов вам понятна, то с инвариантным все будет просто — он сочетает в себе функциональность обоих вышеупомянутых функторов.

Как вы помните, с помощью функторов мы можем отображать один тип в другой с помощью функции f:

В этой статье мы поговорим о функторах. О функторах из библиотеки Cats, а не о классических функторах, которые мы все знаем и любим. Рассмотрим контравариантные функторы (Contravariant Functors), представленные в Cats в виде тайпкласса Contravariant.

Некоторые из вас, возможно, не знают, что классический функтор (Functor) с операцией map, который мы ежедневно используем в наших Scala Cats-проектах, на самом деле является ковариантным функтором (Covariant Functor). Также хочу отметить, что термин "Вариантность" (Variance) применительно к функторам не имеет ничего общего с различными видами вариативности, которые мы знаем, когда речь идет о типах и параметрическом полиморфизме.

Типичный функтор в терминах функционального программирования Scala представляет собой тайпкласс, оперирующий типами высших порядков (higher-kinded type), что оказывается весьма полезным, когда мы хотим абстрагироваться и обобщить наши API.

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

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

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

Тема вариантов в программировании вызывает кучу сложностей в понимании, по мне это проблема в том, что в качестве объяснения берут не всегда успешные метафоры - контейнеры.

Я надеюсь что может у меня получиться объяснить эту тему с другой стороны используя метафоры “присвоения” в разрезе лямбд.

Зачем вообще эта вариантность нужна ?

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

Ко-вариантность это о типах данных и их контроле со стороны компиляторов. И ровно с этого места надо откатиться и сказать о типах данных и зачем это нам нужно.

Данная статья является продолжением заметки “Проектируем интенты с Apache NlpCraft” и содержит детальное описание возможностей языка определения интентов NlpCraft IDL, созданного для использования в NLP проектах основанных на системе Apache NlpCraft. Поддержка NlpCraft IDL добавлена в систему начиная с версии 0.7.5.   

Новая версия декларативного языка определения интентов, получившая название NlpCraft IDL (NlpCraft Intents Definition Language), значительно упростила процесс работы с интентами в диалоговых и поисковых системах, построенных на базе проекта Apache NlpCraft и вместе с тем расширила возможности системы.  

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

Сегодня у нас особый день: состоялся первый релиз этого года — IntelliJ IDEA 2021.1! Обновление уже доступно на нашем сайте и в Toolbox App. Кроме того, можно обновиться из самой IDE или с помощью snap-пакета, если вы являетесь пользователем Ubuntu.

Какой самый стремительный взлет в Лиги наций УЕФА?

С момента запуска Лиги наций УЕФА прошло целых два розыгрыша и уже можно подвести промежуточные результаты)

Многие начинающие и не очень 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. Но такой подход чреват тяжёлыми последствиями, когда приложение выходит в релиз и на бой. Я как человек, имеющий ещё и плюсовый бэкграунд, прекрасно знаю, что некоторые ситуации невозможно предугадать даже очень внимательно вглядываясь в код. А потом искать их причины днями, неделями, иногда месяцами. Потому что кто-то в самом начале, в месте возникновения ошибки не объявил о возможности их возникновения.