Scala *

Предыстория:
мой основной бэкграунд - Java бэкенд. В какой-то момент стала интересна Scala. Я поработал около года в маленьком стартапе, где мы переписывали бэкенд с Python на Scala. Затем через некоторое время я начал искать варианты с переездом в цивилизованные страны и получил 4-5 офферов на Scala в нескольких Европейских странах и 1 оффер на Java… Так я оказался в Австралии. И без Scala. 

Сложно сказать, почему я сделал такой выбор, но естественно через некоторое время я задумался, а не стоит ли попытаться воплотить свою мечту и все же найти компанию, которая бы использовала Scala не только для Data-Science, но и для разработки бэкенда.

В общем, открыл я ЛинкедИн в надежде посмотреть и повыбирать вакансии, и был просто шокирован...

Привет! В этой статье я хочу рассказать, как из модного микросервисного приложения можно сделать рабочую, управляемую систему с помощью трех проверенных годами методик: на примере проекта внутренней performance-based рекламы Joom.

Только что вышла очередная версия плагина Big Data Tools — плагина для IntelliJ IDEA Ultimate, DataGrip и PyCharm, который обеспечивает интеграцию с Hadoop и Spark, позволяет редактировать и запускать интерактивные блокноты в Zeppelin.

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

• соединяться с Hadoop и Spark теперь можно через SSH-туннели, создающиеся парой щелчков мыши;
• мониторинг Hadoop может ограничивать объем данных, загружаемых при просмотре списка приложений.

Fetch — это библиотека Scala для организации доступа к данным из файловых систем, БД, веб-сервисов и любых других источников, данные из которых можно получить по уникальному идентификатору. Библиотека написана в функциональном стиле и основана на Cats и Cats Effect. Предназначена для композиции и оптимизации выполнения запросов к разным источникам данных. Она позволяет:

• запрашивать данные из нескольких источников параллельно;
• запрашивать данные из одного источника параллельно;
• объединять запросы к одному источнику в один запрос;
• производить дедупликацию запросов в каждой из перечисленных ситуаций;
• кэшировать результаты запросов.

Для этого в библиотеке предоставляются средства, которые позволяют писать чистый бизнес-код без низкоуровневых конструкций для осуществления перечисленных оптимизаций.
В примерах используется последняя на момент написания версия Fetch — 1.3.0.

Перевод статьи подготовлен в преддверии старта курса «Scala-разработчик»

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

Однако, когда дело доходит до определения серверной логики для конечных точек (то есть, что должно произойти, когда их конечные точки интерпретируются как сервер и подвергаются воздействию внешнего мира), приоритеты у них разнятся. К нашей великой удаче, все три подхода теперь покрыты tapir!

Читаемость кода упрощает как процесс написания программ, так и последующие действия – от отладки и оптимизации до тестирования и сопровождения.

Один из эффективных способов для понимания кода – применение функциональной парадигмы программирования. Основная идея функционального программирования состоит в представлении процесса вычислений как последовательного изменения состояний без хранения где-либо самих состояний. В качестве примера системы, в которой хорошо реализован функциональный подход, часто приводят Haskell, а также Erlang или Scala. Внедряя такой подход в распространенные языки, такие как JS или Swift, можно добиться как улучшения читаемости, так и тестируемости.

Конечно, нужна некоторая предварительная практика, без которой чтение кода оказывается занятием трудоемким, но после знакомства с основными элементами функционального программирования все становится заметно проще. Нужно понимание, что такое функтор, моноид и монада. Дадим определения каждому из базовых понятий, пусть не строгие, но достаточные для практического применения в контексте нашего повествования.

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

Предлагаю вашему вниманию еще один вариант, не совсем пятничный, а скорее субботний: FizzBuzz на Scala, functional style.

Я несколько раз начинал читать статьи из серии «Введение в функциональное программирование», «Введение в Теорию Категорий» и даже «Введение в Лямбда Исчисление». Причем и на русском, и на английском. Каждый раз впечатление было очень сходным: во-первых, много новых непонятных слов; во-вторых, много новых определений, которые возникают из ниоткуда; в-третьих, совершенно непонятно, как это использовать.

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

Попытки использовать как-то в работе изученные концепции разбивались о полное непонимание, как применить полученное глубокое знание. Ведь, напомню, что парадигму ФП (где-то удобнее, где-то не очень, но) можно использовать практически в любом ЯП, совсем необязательно для этого изучать условный Хаскель.

1. Как прикрутить последнюю версию Swagger-Play (модуль Play, позволяющий использовать аннотации swagger-api и генерировать на их основе документацию в соответствии со спецификацией OpenAPI) и как настроить swagger-ui (библиотеку javascript, служащую для визуализации сгенерированной документации)
2. Опишу основные аннотации Swagger-Core и расскажу об особенностях их использования для Scala
3. Расскажу, как правильно работать с классами моделей данных
4. Как обойти проблему обобщенных типов в Swagger, который не умеет работать с дженериками
5. Как научить Swagger понимать ADT (алгебраические типы данных)
6. Как описывать коллекции

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

Курс состоит из шести модулей, каждый из которых завершается финальным экзаменом и практическими заданиями, предоставляя всестороннее изучение реактивной архитектуры. Весь материал иллюстрируется на примере бизнеса сети ресторанов "Реактивное BBQ". В начале эта сеть использовала монолитную модель, но со временем она трансформировалась в сложную систему, которая требует более продвинутого ПО для поддержки своего растущего бизнеса.

Особо интересны два кейса из курса:

• В первом случае рассматривается управление персоналом в ресторане, что демонстрирует принцип эластичности — один из ключевых аспектов реактивных систем.

Вокруг языка Scala всегда было много хайпа и неоднозначных суждений.

Сейчас споры поутихли, но в твиттере появились сообщения об уходе некоторых значимых участников из компаний активно развивающих экосистему языка Scala. В связи с чем в очередной раз пошли разговоры о том, что Scala всё.

В ответ на это один из очень активных членов сообщества (Li Haoyi) описал своё видение дальнейшего пути языка Scala.

Статья у него получилась интересной, посему решил перевести её.

Привет, Хабр! Выношу на ваш суд русскоязычный перевод моей статьи на Medium: Sorting in Scala — a cat shop example. Статья рассчитана на читателей, знающих синтаксис языка Scala и осведомлённых о базовых инструментах стандартной библиотеки.

Если вы работаете с одной базой данных которая поддерживает транзакции вы даже не задумываетесь о консистентности — база все делает за вас. Если же у вас несколько баз, распределенная система или даже к примеру MongoDB до 4 версии — все не так радужно.

Рассмотрим пример — мы хотим сохранить файл в хранилище и добавить ссылку на него в два документа. Конечно же мы хотим атомарности — либо файл сохранен и добавлен в документы либо ни то ни другое (тут и далее используется cats-effects IO):

saveDataToFile(data) // (1)
  .flatMap { file =>
    addFileRef(documentId, file) // (2)
      .flatMap { result =>
        addFileRef(fileRegistry, file) // (3)
          .flatMap { result =>
            ??? // (4, 5, ...)
          }
          .handleErrorWith { error =>
            // revert (2)
            removeFileRef(documentId, file).attempt >> IO.raiseError(error)
          }
      }
      .handleErrorWith { error =>
        // revert (1)
        removeFile(file).attempt >> IO.raiseError(error)
      }
  }

Уже непросто? Легко представить как количество операций растет и образуется Pyramid of doom.

Но мы же программисты! Давайте обобщим проблему и напишем код, который позволит избежать ненужной сложности и возможных ошибок.

Приветствую, Хабр! Предлагаю вашему вниманию небольшую пятничную статью про Java, Scala, ненормальных программистов и нарушенные обещания.

Простые наблюдения иногда приводят к не очень простым вопросам.

Вот, к примеру, простой и внешне, пожалуй, даже тривиальный факт, гласящий, что в Java можно расширять любой не-final класс и любой интерфейс в области видимости. И другой, тоже достаточно простой, гласящий, что Scala-код, скомпилированный для JVM, может использоваться из Java-кода.

Сочетание этих двух фактов, однако, заставило меня задаться вопросом: а как поведёт себя с точки зрения Java какой-нибудь класс, который в Scala является sealed, т.е. не может быть расширен внешним относительно его собственного файла кодом?

Декомпилированный Scala-класс в представлении художника. Источник: https://specmahina.ru/wp-content/uploads/2018/08/razobrannaya-benzopila.jpg

В качестве подопытного кролика я взял стандартный класс Option. Скормив его декомпилятору, встроенному в IntelliJ Idea, получаем примерно следующее:

// опустим импорты, они сейчас не слишком интересны
public abstract class Option 
implements IterableOnce, Product, Serializable {
    // кучка реализаций методов
    public abstract Object get();
    // ещё кучка реализаций методов
}