Scala *

Совсем недавно я перешел с горячо любимого мной объектно-ориентированного C++ на новый для меня и еще не совсем понятный функциональный Scala. Причины перехода — совершенно отдельная история. Но одной из них было наличие достаточно хорошей, судя по отзывам, поддержки модели акторов — с помощью библиотеки Akka. Я давно мечтал опробовать на собственном опыте все описываемые преимущества этой технологии, а существующие реализации на C++ (CAF_C++ и Theron), которые я немного повертел в небольших тестах, оказались достаточно сырыми для моих нужд. Наиболее каноническое же (по моему мнению) решение модели акторов — Erlang, — я отмел, так как посчитал, что для его освоения мне понадобится слишком много времени, да и не факт, что я смогу найти необходимые мне сторонние библиотеки для этого далеко не универсального языка. Поэтому в результате выбор мой пал именно на Scala в связке с Akka, тем более что Scala я когда-то давно уже начинал изучать, но забросил за нецелесообразностью. Однако, как оказалось, на этот раз время для своего эксперимента я выбрал не самое удачное, в чем я убедился только после того, как достаточно солидная часть проекта была уже завершена.

Добрый вечер господа читатели. Сегодня мне хотелось бы пролить немного света на такую замечательную часть scala core под названием Future. Собственно существует документация на официальном сайте, но там идет объяснение как работать с ним при помощи event driven подхода. Но при это Future является также и монадой. И в данной статье я хотел привести примеры и немного растолковать как их надо использовать в этом ключе (а точнее свое видение этого вопроса). Всех желающим ознакомится с вопросом прошу под кат.

Этим постом, я попробую начать серию переводов официальной документации, об инструменте, который при текущем росте языка Scala становится все более востребованным, но о котором тем не менее очень мало информации на русском языке.
Речь пойдет о sbt — системе сборки проектов для языка Scala (хотя, важно упомянуть, что Java проекты (и вообще любые другие) им так же могут собираться).
Статья является началом перевода документации с сайта проекта scala-sbt.org и так как это мой первый опыт перевода — буду рад любым замечаниям и правкам.
Так же, из-за того, что пока перевод оформлен в виде статьи, я буду пропускать моменты, которые смотрелись бы не совсем корректно, в контексте отдельной части руководства.

Здравствуй, Хабр.

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

Это первая часть из серии статей, в которой мы уделим внимание базовой структуре приложения. Ориентирована на людей знающих Java, работавших со Spring, Hibernate, JPA, JSP и другими 3-4ех буквенными сокращениями. Я попытаюсь рассказать как максимально быстро и безболезненно начать использовать Scala в ваших проектах и по-другому проектировать ваше новое приложение. Все это будет вокруг проекта, который должен выполнять ряд требований:
1. Приложение полностью закрыто, работаем только после авторизации
2. Наличие удобного API (REST мы забудем (он уже история) и напишем что-то вроде Google AdWords API, со своим SQL like запросником)
3. Возможность запуска на сервере приложений так и без него
4. i18n
5. Миграция БД
6. Среда для разработки должна разворачиваться через Vagrant
7. И, по мелочи, логирование, развертывание…

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

Добрый день, хабр!

Решил написать небольшой обзор с примерами на легковесный ORM для Scala — Squeryl 0.9.5

Начнем с основных достоинств данного фреймворка.

1) Squeryl предоставляет DSL для SQL запросов. К примеру

def songs =  from(MusicDb.songs)(s => where(s.artistId === id) select(s))

def fixArtistName = update(songs)(s =>
  where(s.title === "Prodigy")
  set(
    s.title := "The Prodigy",
  )
) 

Синтаксис напоминает C# LINQ. Как вы могли заметить в запросах используются лямбда выражения, что значительно сокращает объем кода.

В данном примере метод songs возвращает объект Query[Song] который реализует интерфейс Iterable, что позволяет работать с ним как с обычной коллекцией.

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

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

В обновлённом варианте библиотеки synapse-frames исключительно просто описываются иерархические структуры данных и представляются любые подмножества таких структур.

Когда-то давно я уже поднимал тему применения Scala в игровом сервере. Тогда это был совсем простой пример использующий только Scala. С тех времен много воды утекло. Scala и Akka развиваются, но статей по ним что-то не прибавляется. А тема очень интересна. В общем хочется продолжить цикл статей про сервер на Scala. В этой статье будет описана общая архитектура решения. А так же что дает использование Scala и Akka. Примеры кода.

Я никогда не смогу ходить! Потому что я ползаю.
—Цитаты великих

    Меня всегда учили прежде всего здороваться, так что — здравствуйте. Сегодня я расскажу про творческие (и не очень) муки, страдания и боль, которые я испытывал на протяжении определенного периода своей жизни, который я обозначу как ПРОЕКТ. Сначала он был на JavaScript (node.js), а теперь он на Scala (Play). Сразу скажу, что я — один из самых субъективных негодяев в обозримой Вселенной, поэтому некоторые обороты, высказывания и иже с ними могут быть восприняты уважаемыми читателями весьма неоднозначно. Короче, я предупредил. И у меня еще одна небольшая просьба — если уж взялись прочитать статью, то не кидайтесь сразу строчить разоблачающие комментарии. Дочитайте. Я не Пастернак, правду говорю. И вообще, почти все спорные моменты так или иначе освещаю, объясняю.

Я постоянно замечаю, что «О, святые небеса, Scala — это сложно!». Знаете, возможно это правда. Давайте попробуем посмотреть на эту сложность и пройтись по основным отличиям Scala от других объектно-ориентированных языков (например, Java или C++).

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

Удивительно, но на хабре пока тему макросов в Scala рассматривают не слишком-то активно; последний пост
с серьёзным рассмотрением макросов был аж целый год назад.

В данном посте будет подробно рассмотрено написание простого макроса, предназначенного для генерации кода десериализации JSON в иерархию классов.

При построении многослойных («enterprise») систем часто оказывается, что создаются ValueObject'ы (или case class'ы), в которых хранится информация о каком-либо экземпляре сущности, обрабатываемом системой. Например, класс

case class Person(name: String, address: Address)

Такой способ представления данных в системе обладает как положительными свойствами:

• строго типизированный доступ к данным,
• возможность привязки метаинформации к свойствам с помощью аннотаций,

так и некоторыми недостатками:

• если сущностей много, то таких классов также становится довольно много, а их обработка требует много однотипного кода (copy-paste);
• потребности отдельных слоёв системы в метаинформации могут быть представлены аннотациями к свойствам этого объекта, но возможности аннотаций ограничены и требуют использования reflection'а;
• если требуется представить данные не обо всех свойствах объекта сразу, то созданные классы использовать затруднительно;
• затруднительно также представить изменение значения свойства (delta).

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

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

Совсем недавно вышла Java 8. И у меня возникло желание написать что-то с использованием новых плюшечек, которые дает 8-ерка.
Конкретно Лямбы, новый collection api, позволяющий работать с коллекциями в более функциональном стиле и default-методы в интерфейсах.

Статья является кратким обзором моего опыта по интегрированию Java 8, Spring MVC, Hibernate и SSP.

Кому интересно, прошу под кат.

Уважаемые коллеги,

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

А под катом я расскажу, о том, как работают современные IDE. И как проект, над которым я сейчас работаю, может помочь вывести индустрию разработки веб-редакторов на новый уровень.

Тихо и незаметно вышла новая версия Scala. Пруф
В релиз вошло много изменений и улучшений.

Дорогие любители Scala! Пользуемся последним моментом, чтобы сообщить вам об очередной встрече Scala User Group в Москве. Она пройдет в эту пятницу, 25 апреля на территории НИИ «Восход». Начало в 19:30. Для того, чтобы прийти на встречу, необходимо заполнить форму регистрации: docs.google.com/forms/d/1tYo8unkWNpQYN-lCwoZz4mL7AcvNQGi_Zt1O7TTpknA/viewform (все поля обязательны, ФИО должны вводиться целиком). Последний день регистрации — сегодня, 23 апреля.

При написании собственных веб-приложений часто возникают такие ситуации, в которых приходится делать выбор между синхронным и асинхронным выполнением запросов. С одной стороны, идея синхронной работы выглядит вполне логичной: мы запускаем некоторый процесс, дожидаемся его завершения и после этого продолжаем работу. Но на деле такой подход хорош только в случае простых вычислений. Представьте, что в процессе выполнения вам нужно, к примеру, сделать сложный запрос к базе данных — а то и, еще лучше, отправить запрос к другому серверу и дождаться от него результатов. В этом случае дальнейшая работа потока будет остановлена на довольно продолжительное время — а это, понятное дело, далеко не всегда является приемлемым. Именно в таких случаях на помощь приходят асинхронные запросы. Давайте посмотрим, как работа с ними реализована в Play framework.

Play! и Lift, — эти два фреймворка являются олицетворением того, куда движется основной поток Scala веб-разработчиков. Воистину, попробуйте поискать на Stack Overflow фреймворки для Scala и вы поймете что я прав. Я верю, что процент здравомыслящих людей, которым надоели сложные комбайны, велик, поэтому расскажу про «другой» фреймворк Xitrum.

В прошлый раз мы провели ознакомительную встречу. Собралось около 25 человек, мы узнали кто в Москве занимается разработкой на Scala и какие есть интересные проекты. Главной темой выбрали курс по реактивному программированию на Coursera, который как раз тогда подходил к концу.

В этот раз мы соберёмся послушать и обсудить два доклада:

1. Алексей Иванов приедет из Питера и расскажет доклад «Monadic Bakery with Spray and Scalaz»,
   про то почему Spray и ScalaZ — не страшные звери, а хорошие друзья;
2. Владимир Успенский расскажет про теорию типов и тем, как она связана с обычной разработкой в докладе:
   «Теория типов, или как мы занимаемся математикой, программируя на Scala».

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

Об авторе:
Pavel Fatin работает над Scala plugin'ом для IntelliJ IDEA в JetBrains.

Введение

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

Содержание статьи составляет основу моего выступления на JavaDay конференции (слайды презентации).

А сейчас нужно обязательно дунуть, потому что если не дунуть, то ничего не получится.
—Цитаты великих

И здравствуйте!

Сегодня мы поговорим о неявном в языке Scala. Кто еще не догадался — речь пойдет об implicit преобразованиях, параметрах, классах и иже с ними.Все новички, особенно любители питона с зеновским Explicit is better than Implicit, обычно впадают в кататонический ступор при виде подкапотной магии, творящейся в Scala. Весь компилятор и принципы в целом охватить за одну статью удастся вряд ли, но ведь дорогу осилит идущий?