Вводная

Часть 2. Генераторы

В вводной статье серии вы, надеюсь уже, успели познакомиться с генераторами. В этом туториале мы закрепим полученные знания, научимся писать собственные (в том числе рекурсивные) генераторы. Хотя он и посвящен генераторам, про свойства мы тоже не забудем. Более того, мы будем их активно использовать, демонстрируя всю мощь механизма генераторов. Рассмотрим механизм предусловий (preconditions). Возможно, более логичным было бы посвятить свойствам вторую статью серии и, возможно, это стало бы правильным решением. Однако, по моим личным наблюдениям, наибольшие трудности вызывают именно генераторы. Свойства мы рассмотрим в следующей статье.

Про ScalaCheck

Часть 1. Введение.

ScalaCheck — это комбинáторная библиотека, значительно облегчающая написание модульных тестов на Scala. В ней используется подход property-based тестирования, впервые реализованный в библиотеке QuickCheck для языка Haskell. Существует множество реализаций QuickCheck: как для Java, C, а так же других языков и платформ. Использование данного подхода позволяет значительно сократить время на разработку тестов.

Эта серия статей во многом похожа на мою предыдущую, посвященную Parboiled, поэтому и структура повествования будет похожей. Я расскажу вам, для чего всё это нужно, затем мы научимся смотреть на мир сквозь призму свойств и генераторов, а потом перейдём к более сложным вещам. Заинтересовало? Прошу под кат.

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

Введение

Типы и ограничения

• Тип Int в Scala/Java имеет размер 32 бита
• Использовать можно биты: 0..30 — 31, поскольку 32-ой бит является знаковым
• Полиномы должны быть представлены числами в диапозоне 0..29
• Неприводимые полиномы (или модули) имеют диапозон 1..30
• Конечное поле имеет элементов

Реализация

В нашем отделе бигдаты часть данных хранится в Aerospike. Потребителей довольно много, среди них два приложения, написанных на Scala, взаимодействие с базой в которых будет расширено в связи с постоянно растущими требованиями бизнеса. Единственным приличным драйвером для нас был джавовый клиент, упомянутый на сайте самой базы данных aerospike.com (http://www.aerospike.com/docs/client/java). Конвертация скаловых типов данных (а особенно иерархических) в соответствующие аэроспайковские типы приводит к большому количеству бойлерплейта. Чтобы этого избежать, необходим более удобный, а заодно и типобезопасный интерфейс.

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

В какой то момент разработки приложения, каждый из нас приходит к тому, что нам нужно больше информации о том, что происходит внутри приложения или же в возможности мониторить приложение. В случае с Play Framework уже существует готовое решение в виде отличной библиотеки с открытым исходным кодом Kamon в паре с модулем kamon-play.

Но сегодня мы собираемся взглянуть на альтернативное решение, интеграцию и использование Drowizard Metrics ранее известное как Codahale Metrics с Play Framework.

Хочу рассказать про свою небольшую библиотеку Dependency Injection на Scala. Проблема которую хотелось решить: возможность протестировать граф зависимостей до их реального конструирования и падать как можно раньше если что-то пошло не так, а также видеть в чем именно ошибка. Это именно то, чего не хватает в замечательной DI-библиотеке Scaldi. При этом хотелось сохранить внешнюю прозрачность синтаксиса и максимально обойтись средствами языка, а не усложнять и влезать в макросы.

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

Введение

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

Подготовка

Сначала опишем структуру данных, в которой будет храниться исходная математическая функция. Опишем трейт MathAST:

sealed trait MathAST

Это третья статья об использовании Scala в тестировании. Сегодня будут рассмотрены примеры использования Apache Camel для создания тестовых заглушек, а также компонентов информационной системы.

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

Для разовой проверки интеграции мы бы использовали простое Java или Scala приложение, сценарий Apache JMeter или SoapUI. Но нам нужна система, которая постоянно работает, отвечает на запросы и не требует действий со стороны тестировщика — запустил и забыл. Для решения такой задачи мы можем создать приложение, основанное на фреймворке Apache Сamel.

Наша команда, аналогично с автором статьи, уже почти как год перешла со Scala на Kotlin в качестве основного языка. Мое мнение во многом совпадает с автором, поэтому предлагаю вам перевод его интересной статьи.

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

Ниже я хочу привести примеры, которые мне нравятся в Scala и Kotlin, а также их сравнение в том, как они реализованы в обоих языках.

import scala.xml.{Node => XmlNode}

def getByPath(path: List[String], root: XmlNode): Option[XmlNode] =
  path match {
    case name::names =>
      for {
        node1 <- root.child.find(_.label == name)
        node2 <- getByPath(names, node1)
      } yield node2
    case _ => Some(root)
  }

• Извлекать данные из JSON и, возможно, других древоподобных структур, а не только из XML;
• Возвращать сообщение об ошибке, если данные не найдены.