Scala *

Приветствую! В этой статье будет показан алгоритм поиска ближайших к заданному слов из корпуса в терминах метрики Левенштейна. Наивным spellchecking-ом назван потому, что не учитывает ни морфологии, ни контекста, ни вероятности появления скорректированного слова в предложении, однако в качестве первого приближения сойдет вполне. Также алгоритм может быть расширен на поиск ближайших последовательностей из любых других сравнимых объектов, нежели простой алфавит из Char-ов, и, после допиливания напильником, его можно приспособить и для учета вероятностей появления скорректированных слов. Но в данной статье сосредоточимся на базовом алгоритме для слов определенного алфавита, скажем, английского.

Код в статье будет на Scala.

Всех заинтересовавшихся прошу под кат.

В процессе поддержки различных проектов я несколько раз попадал в ситуацию, при которой по причине неправильной работы с Promise возникали проблемы на продакшне. Причём паттерн этой самой неправильной работы всегда был один и тот же, но скрывался он в разных обличьях. Более того, ошибочный код был написан различными людьми. К тому же, ни в одной статье по работе с Promise я толком не нашёл упоминание проблемы, которую хочу осветить. Так что предполагаю, что многие забывают про проблему, про которую я расскажу.

Интересно почитать много примеров асинхронного кода на Scala, с промисами, фьючами и акторами? Добро пожаловать под кат!

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

В скором времени у нас выходит изысканная новинка для разработчиков высшего класса — "Реактивные шаблоны проектирования".

Автор книги Роланд Кун — звезда первой величины в области распределенных систем, один из разработчиков Akka. Под катом предлагаем перевод его программной статьи о распределенных системах и акторной модели, размещенной на сайте GitHub

Планов на декабрь много: и завалы на проекте разгрести, и новогодние праздники распланировать. Если среди всей этой предновогодней беготни захотелось пищи для ума, айда к нам — 15 декабря обсудим функциональное программирование. Мы поделимся секретами написания быстрого бекенда, вместе разрушим десяток мифов о ФП и устроим холивар про будущее ФП/ООП.

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

Model-Updater-View — функциональный паттерн, успешно применяемый в языке Elm в основном для разработки пользовательских интерфейсов. Что бы им воспользоваться надо создать тип Model, представляющий полное состояние программы, тип Message, описывающий события внешней среды, на которые программа должна реагировать, меняя свое состояние, функцию updater, которая из старого состояния и сообщения создает новое состояние прораммы и функции view, которая вычисляет по состоянию программы требуемые воздействия на внешнюю среду, которые порождают события типа Message. Паттерн очень удобный, но у него есть маленький недостаток — он не позволяет описать какие события имеют смысл для конкретных состояний программы.

Схожая проблема возникает (и решается) и при использовании ОО-паттерна State.

Язык Elm простой, но очень строгий — он проверяет, что функция updater хоть как-то обрабатывает все возможные сочетания модели-состояние и сообщения-события. По этому приходится писать лишний, пусть и тривиальный — как правило оставляющий модель без изменений, код. Я хочу продемонстрировать, как этого можно избежать в более сложных языках — Idris, Scala, C++ и Haskell.

Про микросервисы не рассказывал только ленивый. Вот и мы не ленивые. Решили поговорить о микросервисах. Но только не ещё раз о том, что это такое, а о том, как мы их сервируем в 2ГИС. Например, наши бекенды держат 15 млн пользователей в месяц. На встрече поговорим о деплое, координации и согласованности данных.

Рад объявить о первом крупном обновлении глобальной тепловой карты в Strava Labs c 2015 года. Это обновление включает в себя в шесть раз больше данных, чем раньше —  в сумме 1 миллиард активностей со всей базы Strava по сентябрь 2017 года.

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

• 1 миллиард активностей
• 3 триллиона точек долготы/широты
• 13 триллионов пикселей после растрирования
• 10 терабайт исходных данных
• Общая дистанция маршрутов: 27 миллиардов километров
• Запись общего времени активности: 200 тысяч лет
• 5% земной суши покрыто тайлами

Тепловая карта Москвы демонстрирует функцию поворота/наклона в Mapbox GL

Привет, Хаброжители! Наконец-то мы можем предложить вам результаты титанического труда наших переводчиков и редакторов – долгожданное классическое издание по языку Scala. Все, кому известна аббревиатура JVM и не чуждо функциональное программирование, несомненно, оценят эту книгу (переоценить ее невозможно). Основной автор этого фолианта — Мартин Одерски, разработчик и идеолог языка Scala, стоявший у самых его истоков. Эта книга станет незаменимым приобретением для всех серьезных специалистов, имеющих опыт работы с Java и JVM. Авторы преследовали цель научить читателя всему необходимому, чтобы уверенно писать на языке Scala работоспособные и даже боеспособные приложения. Все примеры в издании скомпилированы с использованием Scala версии 2.11.7, за исключением тех, что имеют пометку 2.12, — они скомпилированы с использованием версии 2.12.0-M3

Привет!

2 декабря ждем всех, кто любит делать это функционально на третьей конференции FPConf — конференции о Haskell, Scala, Clojure, Elixir, Kotlin, F# и функциональных подходах в программировании фронтендов, бэкендов и чего угодно на чем угодно. Больше монад, лямбд, замыканий! Всем иммутабельность, друзья :)

Традиционно, приглашаем как опытных функциональщиков, так и тех, кто только хочет получить вдохновение и расширить горизонты.

Цена билета сейчас — 5000 рублей. Регистрация тут.

Что в программе:

Arnaud Spiwack, core-разработчик Coq Proof Assistant, старший архитектор в Tweag I/O

USING HASKELL TO GREAT EFFECT

It is beyond cliché, nowadays, to say that testing is really important. This is even more so in I/O intensive applications because so many things can go wrong. Unfortunately, testing I/O intensive applications is particularly hard. We have to mock all our files, data-bases, and so on. But even so, we're only scratching the surface: so many things can go wrong. How do we test for absence of deadlocks? Of races?

I came to the conclusion that Haskell's insistence on purity made it, paradoxically, one of the best languages to write I/O intensive programs. The reason for this is that Haskell makes it very easy to mock every single aspects of the I/O fabric, hence testing is more powerful. Up to checking for the absence of deadlocks and races. This talk will discuss the programming patterns which emerge from this point of view, and, of course, encourage you do use them in your programs.

В случае с SEMrush бессмысленно спрашивать «какие языки и технологии использует компания»: здесь каждой команде предоставляют максимальную степень автономности, сводя «общее для всех» к минимуму. А вот конкретную команду вполне есть о чём расспросить.

Мы узнали, что в одном из проектов используют Scala, C++, Spark и ClickHouse. Выбор Scala сам по себе нестандартный, сочетание с C++ можно встретить ещё реже, СУБД ClickHouse от Яндекса тоже не самый распространённый выбор — поэтому мы решили задать несколько вопросов о том, как со всем этим живётся. На них нам ответил Александр Морозов.

У Scala репутация языка, с которым сложности подстерегают с разных сторон: порог входа выше, чем у Java, а разработчиков куда меньше (так что может быть сложнее собрать команду). В итоге российские компании нечасто решаются его использовать. Но в Tinkoff.ru активно используют далеко не первый год — и мы решили расспросить компанию, как на практике живётся с Scala. Поскольку сложности могут быть и техническими, и кадровыми, вопросы задали двум разным сотрудникам: руководителю отдела разработки программных интерфейсов Роману Докучаеву и руководителю HR-проектов Ольге Шпунтенко.

Простой код на Java: generic интерфейс, класс который его реализует, и метод, принимающий его экземпляр:

//Gen.java:
public interface Gen<A> {
    A value();
}

//GenInt.java:
public class GenInt implements Gen<Integer> {
    private final int i;
    public GenInt(int i) {
        this.i = i;
    }
    @Override
    public Integer value() {
        return i;
    }
}

//GenTest.java:
public class GenTest {
    public static <A extends Gen<T>, T> T test(A a) {
        return a.value();
    }
    public static void main(String[] argv) {
        GenInt g = new GenInt(42);
        Integer i = test(g);
    }
}

Он компилируется и даже запускается. Как вы думаете, что будет, если вам захочется вызывать метод test из Scala?

object TestFail extends App {
  val genInt = new GenInt(42)
  val i = GenTest.test(genInt)
}

По долгу работы мне приходится сталкиваться с проектированием и разработкой распределенных приложений. Такие приложения часто используют различные средства межпроцессного взаимодействия для организации взаимодействия компонентов. Особые сложности возникают в процессе реализации алгоритмов, обрабатывающих связанные данные распределенно. Для поддержки таких задач используются специализированные системы распределенной координации. Самым популярным и широко используемым продуктом является Apache Zookeeper.

В конце мая я оказался среди слушателей конференции Scala Days в Копенгагене. Одним из ключевых спикеров был создатель языка Scala Мартин Одерски. Он рассказал о развитии языка и, в частности, о разработке компилятора, названного Dotty. Планируется, что на основе Dotty будет разработан новый компилятор для версии 3.0.

Мартин не раз выступал на эту тему, и я бы хотел собрать здесь всю актуальную информацию о Dotty – новые ключевые возможности и элементы, удаленные за ненадобностью.


Мартин Одерски. План развития Scala на ближайшие несколько лет

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

Представляю вашему вниманию перевод статьи Павла Фатина Scala Collections Tips and Tricks. Павел работает в JetBrains и занимается разработкой Scala плагина для IntelliJ IDEA. Далее, повествование идет от лица автора.

В этой статье вы найдете упрощения и оптимизации, характерные для повседневного использования API Scala коллекций.

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

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

Тем не менее, эти рецепты ценны сами по себе. Они могут помочь вам углубить понимание стандартной библиотеки коллекций Scala и сделать ваш код быстрее и выразительнее.

Обновление:
Если вы испытываете тягу к приключениям,
вы можете узнать, как помочь в развитии IntelliJ плагина для Scala и попробовать свои силы в реализации, подобрав подходящую инспекцию.

Play framework — очень гибкий инструмент, но информации о том, как изменить формат route-файла, на просторах интернета мало. Я расскажу о том, как можно заменить стандартный язык описания маршрутов на основе route-файла на описание в формате RAML. А для этого нам придется создать свой SBT-плагин.

Бывает так, что когда человек начинает писать на Kotlin, Scala или %language_name%, он делает манипуляции с коллекциями так, как привык, как “удобно”, как “понятнее” или даже “как быстрее”. При этом, разумеется, используются циклы и изменяемые коллекции вместо функций высшего порядка (таких как filter, map, fold и др.) и неизменяемых коллекций.

Эта статья — попытка убедить ортодоксов, что использование “этой вашей функциональщины” не влияет существенно на производительность. В качестве примеров использованы куски кода на Java, Scala и Kotlin, а для измерения скорости был выбран фреймворк для микробенчмаркинга JMH.

Scala богата выразительными средствами, за что ее и не любят опытные программисты на классических ООП-языках. Неявные параметры и преобразования — одна из самых спорных фич языка. Слово "неявные", уже как-бы намекает на что-то неочевидное и сбивающее с толку. Тем не менее, если с ними подружиться, implicit'ы открывают широкие возможности: от сокращения объема кода до возможности многие проверки делать в compile-time.

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

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