Как стать автором
Поиск
Написать публикацию
Обновить
6.67

Scala *

Мультипарадигмальный язык программирования

Сначала показывать
Порог рейтинга
Уровень сложности

Декомпиляция Java-методов на продуктивном приложении под нагрузкой – миф или реальность?

Время на прочтение3 мин
Количество просмотров5.5K
Тестирование, несомненно, является одним из китов, на которых стоит разработка приложений. Как и любой характерный кит, тестирование может зафонтанировать багами и долго не останавливаться. Но главный вопрос заключается в достаточности тестового покрытия – все ли баги по написанным тест-кейсам удастся отловить? Возможно, некоторые появятся только под пользовательской нагрузкой. Для выявления оных, как правило, детонирует обращение пользователя и далее задействуется следующая цепная реакция: специалист Help Desk, вторая линия поддержки и, если повезет, сообщение о нештатной работе попадет в руки разработчика. Да, инцидент может также прийти от системы APM-мониторинга (если она у вас есть, конечно). Но все эти вещи не позволят однозначно определить, какие значения принимали переменные до возникновения исключения. В посте мы как раз поговорим о решении, призванном в помогать в подобных ситуациях.


Собрать монстров в узелок

Какое место занимает язык Scala в ИТ-индустрии

Время на прочтение7 мин
Количество просмотров123K


Язык программирования Scala является «симбиозом» Java и C#. Это не первый язык, комбинирующий ООП с функциональным подходом, но он начал набирать обороты в тот момент, когда развитие Java замедлилось. Более того, создатели Scala решили, что язык должен работать на виртуальной машине JVM и предоставлять доступ к Java-библиотекам.

Мартин Одерски начал разрабатывать Scala в начале 2000-х в стенах Лаборатории методов программирования EPFL. Он же ранее занимался разработкой Generic Java и компилятора Java фирмы Sun.
Читать дальше →

Dependency Injection с проверкой корректности на Scala средствами языка

Время на прочтение5 мин
Количество просмотров5.5K

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


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

Читать дальше →

Scala или не Scala? Вот в чем вопрос

Время на прочтение4 мин
Количество просмотров23K


Дискуссия вокруг Scala не стихает уже много лет, разворачиваясь в основном на поле противостояния с Java. Действительно, несмотря на общую платформу, языки разные.

Аргументы за Scala известны:

1. Scala лаконичная;
2. Scala функциональная;
3. Scala крутая и современная;

В ответ на то, что Scala медленно загибается, Мартин Одерски заявил следующее: «В 2015-м было затишье, но вот в 2016-м развитие Scala должно ускориться».

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

Ну и в конце дам пару ссылок на популярные статьи по теме за последние несколько лет, если вдруг вы какие-то из них пропустили.
Читать дальше →

Аналитическое вычисление производной функции на языке Scala

Время на прочтение7 мин
Количество просмотров14K

Введение


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


Подготовка


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

sealed trait MathAST

И его наследников:

Читать дальше →

Создаем заглушки сервисов для интеграционного тестирования на Apache Camel (с использованием Scala DSL)

Время на прочтение14 мин
Количество просмотров17K
image


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


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


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

Читать дальше →

Scala vs Kotlin (перевод)

Время на прочтение7 мин
Количество просмотров49K

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


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


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

Читать дальше →

Как написать SQL-запрос на Slick и не открыть портал в ад

Время на прочтение9 мин
Количество просмотров17K


Slick — это не только фамилия одной из величайших солисток всех времён, но и название популярного Scala-фреймворка для работы с базами данных. Этот фреймворк исповедует «функционально-реляционный маппинг», реализует реактивные паттерны и обладает официальной поддержкой Lightbend. Однако отзывы разработчиков о нём, прямо скажем, смешанные — многие считают его неоправданно сложным, и это отчасти обоснованно. В этой статье я поделюсь своими впечатлениями о том, на что стоит обратить внимание при его использовании начинающему Scala-разработчику, чтобы в процессе написания запросов случайно не открыть портал в ад.
Читать дальше →

Рефакторинг при помощи композиции Клейсли

Время на прочтение4 мин
Количество просмотров12K
В течение довольно длительного времени мы поддерживали приложение, которое обрабатывает данные в форматах XML и JSON. Обычно поддержка заключается в исправлении дефектов и незначительном расширении функциональности, но иногда она также требует рефакторинга старого кода.


Рассмотрим, например, функцию getByPath, которая извлекает элемент из XML дерева по его полному пути.

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;
  • Возвращать сообщение об ошибке, если данные не найдены.

В этой статье мы расскажем, как осуществить рефакторинг функции getByPath, чтобы она соответствовала новым требованиям.
Читать дальше →

Курс молодого бойца для Spark/Scala

Время на прочтение3 мин
Количество просмотров27K
Хабр, привет!

Команда Retail Rocket использует узкоспециализированный стек технологий Hadoop + Spark для вычислительного кластера, о котором мы уже писали обзорный материал в самом первом посте нашего инженерного блога на Хабре.

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


Читать дальше →

Композиция функций на F# и Scala

Время на прочтение7 мин
Количество просмотров13K

Проще говоря о чем все это


Я начал думать о написании данной статьи несколько недель назад, после того, когда я старался объяснить моему 7 летнему чаду что такое математические функции. Мы начали с рассмотрения очень простых вещей. Это прозвучит безумно и наверное несуразно, но я закончил мое вводное объяснение повествованием о композиции функций. Это казалось настолько логичным разъясняя что такое функции, приводя примеры их использования из окружающего мира, говорить о композиции. Цель данной статьи — показать насколько простой и мощной является композиция функций. Начну я с рассмотрения понятия чистой композиции и приземленного разъяснения, после чего мы попробуем немного карри и позабавимся с монадами. Надеюсь вам понравится.

Далее

Производительность Apache Parquet

Время на прочтение9 мин
Количество просмотров15K

Плохой пример хорошего теста


В последнее время в курилках часто возникали дискуссии на тему сравнения производительности различных форматов хранения данных в Apache Hadoop — включая CSV, JSON, Apache Avro и Apache Parquet. Большинство участников сразу отметают текстовые форматы как очевидных аутсайдеров, оставляя главную интригу состязанию между Avro и Parquet.


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


Как любой уважающий себя инженер, я подумал, что было бы неплохо провести полноценные performance-тесты, чтобы наконец проверить, на чьей стороне правда. Результат сравнения — под катом.


Apache Parquet Logo

Читать дальше →

Итоги «QIWI Scaladrom Meetup»

Время на прочтение1 мин
Количество просмотров1.9K
QIWI собрала разработчиков на «Scaladrom» 24 марта
24 марта в 19:00 по МСК в лофте «БАНКА», прошла неформальная встреча Scala-программистов Москвы «QIWI Scaladrom».

Итоговые видеоматериалы во вложении.

Читать дальше →

Ближайшие события

Большой JVM-опрос: версии Java, альтернативные JVM-языки, версии Java EE

Время на прочтение1 мин
Количество просмотров16K
image

С прошлого аналогичного опроса прошло больше года, и пришла пора его повторить и расширить.

Ретроспектива:
Какие версии Java вы используете? — 18 февраля 2015
Какие версии Java вы используете? — 14 февраля 2014

Опросы под катом

Реализация мониторинга и интеграционного тестирования информационной системы с использованием Scalatest. Часть 2

Время на прочтение11 мин
Количество просмотров6.4K


В предыдущей статье Реализация мониторинга и интеграционного тестирования информационной системы с использованием Scalatest мы говорили о создании проекта в Idea и написании простых тестов. В этой части мы рассмотрим некоторые особенности работы фреймворка, а также приемы для решения задач, возникающих в ходе написания тестов.
Более детально остановимся на специфике запуска тестов, разберем детали формирования отчетов, особенности работы с Selenium, а также обратим внимание на таймауты, ожидания, вызовы команд операционной системы, формирование jar файла с тестами
Читать дальше →

Разбавляем асинхронное программирование функциональным на Scala

Время на прочтение7 мин
Количество просмотров9.7K
Приветствую! В этой статье будет показано, как, имея на руках обычные Future-ы, сделать в scala подобие корутин и асинхронные stream-ы. Этакий небольшой туториал по функциональному программированию.

Что это и зачем


Что такое Future человеческим языком
Future — это сущность, описывающая результат некоторых вычислений, который мы получим не сразу, но в будущем. Но есть одна особенность: зачастую мы, не зная еще результата, точно знаем, что мы с ним будем делать. Например, мы попросили у сервера какой-то конфиг, и теперь у нас есть Future[Config]. Сам конфиг мы еще не получили, но точно знаем, что, когда получим, то достанем из него адрес и по этому адресу попросим у сервера картинку (config => Future[Image]). И Future[Config] способна изменяться таким образом, чтобы мы вместо конфига и потом картинки могли получить сразу картинку. Сущности, способные комбинироваться таким способом, называются монадами.

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

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

Применив знания из этой статьи, мы сможем этот процесс описать примерно так:

Код
// Про 'FState' - далее, пока же просто примем, что это - такая необычная Future
def getNextConfig: FState[Config]
def getTemperature(from: String): FState[Int]

case class State(temperature: Int, sumTemp: Long, count: Int) {
  def isGood = ...
}

// Как видим, получается единый асинхронный алгоритм с состоянием, 
// которое извне этого алгоритма не видно
val handle = 
  while_ ( _.isGood)
  {  for (
        config <- getNextConfig();
        if (config.isDefined);  // пустой конфиг - прекращаем выполнение
        nextValue <- getTemperature(config().source);  // грузим значение температуры
        state <- gets[State];  // тут мы берем текущее состояние
        newState = State(nextValue, state.sumTemp + nextValue, state.count + 1);
        _ <- puts(newState);  // .. и меняем его
        _ <- runInUiThread { drawOnScreen(newState) }
  ) yield() }


Или вот так:

Код
val configs: AsyncStream[Config] = ... // получаем откуда-то stream конфигов

def getTemperature(from: String): FState[Int]

case class State(temperature: Int, sumTemp: Long, count: Int)

// Получается то же самое, только вместо зависимости 'getNextConfig'
// мы, по сути, передаем сами данные - stream из конфигов
val handle = 
  foreach(configs) {
    config => for (
        nextValue <- getTemperature(config().source);  // грузим значение температуры
        state <- gets[State];  // тут мы берем текущее состояние
        newState = State(nextValue, state.sumTemp + nextValue, state.count + 1);
        _ <- puts(newState);  // .. и меняем его
        _ <- runInUiThread { drawOnScreen(newState) }
    ) yield()  
  }


Всех, кто заинтересовался, прошу под кат.
Читать дальше →

Слежение за обновлениями из MongoDB Oplog в Sharded Cluster используя Scala и Akka Streams

Время на прочтение5 мин
Количество просмотров4.4K

Введение


Эта статья является продолжением предыдущей опубликованной статьи Tailing the MongoDB Replica Set Oplog with Scala and Akka Streams.
Как мы обсуждали прежде, слежение за обновлениями в MongoDB Sharded Cluster Oplog имеет свои подводные камни по сравнению с Replica Set. Данная статья попытается раскрыть некоторые аспекты темы.
В блоге команды MongoDB имеются очень хорошие статьи, полностью покрывающие тему слежения за обновлениями из MongoDB Oplog в Sharded Clusters. Вы можете найти их по следующим ссылкам:

Так же вы можете найти информацию об MongoDB Sharded Cluster в документации.
Примеры, приведенные в данной статье не следует рассматривать и использовать в продакшн среде. Проект с примерами доступен на github.


MongoDB Sharded Cluster


Из документации MongoDB:
Sharding, или горизонтальное масштабирование, разделение и распределение данных на нескольких серверах или сегментах (shards). Каждый сегмент является независимой базой данных, и в совокупности все сегменты составляют единую локальную базу данных.

Sharded Collection


В продакшин среде каждый узел является Replica Set:


Sharded Cluster Architecture
Читать дальше →

Встречайте IntelliJ IDEA 2016.1

Время на прочтение2 мин
Количество просмотров32K
На прошлой неделе мы выпустили очередное крупное обновление — IntelliJ IDEA 2016.1. Ранее я уже писал подробно о доступных в нем улучшениях, а в этом посте лишь приведу их краткий список, дам ссылки на новые видео, и, конечно, буду рад ответить на ваши вопросы в комментариях.



Читать дальше →

Дружим Scala и Android с помощью Macroid

Время на прочтение11 мин
Количество просмотров6.4K
imageТак как на работе я пишу на старой доброй Enterprise Java, меня периодически тянет попробовать что-то новое и интересное. Так получилось, что в один момент этим новым и интересным оказалась Scala. И вот однажды, просматривая доклады со Scala Days, я наткнулся на доклад Ника Станченко о библиотеке под названием Macroid, которую он написал. В этой статье я попробую написать маленькое приложение для демонстрации её возможностей и рассказать об основных фишках этой библиотеки. Код приложения целиком доступен на Github.

Если вам захотелось узнать, как эта библиотека помогает подружить Scala и Android, добро пожаловать под кат.
Читать дальше →

Вспомнить всё: Java-конференция JET. 28 сентября 2015. Отчёт

Время на прочтение5 мин
Количество просмотров5.4K
Меня зовут Дима и я разработчик. Живу в Минске, люблю посещать зарубежные конференции. Ну вот устал однажды ездить и решил сходить локально. Но выбора было мало. Поэтому вдвоём со своим верным товарищем решили сделать конференцию самостоятельно. Назвали JET. Потому что начинается с J, как и Java, а ещё можно сделать слоган "Let's fly to Java world". Ну что же, как это было?

Открытие


Началось все с выступления организаторов, где мы поделились тем, как зарождалась идея конференции. Рассказали о том, как мы прошли путь в 4 месяца подготовки, и что по итогу получилось. А получилось — 3 потока концентрированных знаний, 300 участников и первый кирпичик в фундаменте дома конференции JET.


Читать дальше →