Программа курса и материалы по Scala

  • Tutorial
Добрый день.

Меня зовут Головач Иван, я практикующий Java Tech Lead с опытом в программировании 10+ лет (Java EE, J2ME, C, C++, M-language, Delphi), который перешел на Scala.

Я подготовил и прочитал как обычные курсы по программированию (Java Core + Junior Java Developer), так и спецкурсы (Multicore Programming for JVM (раз и два)).

В данный момент я стартую спецкурс по Scala и в этом топике хочу поделиться материалами, которые я нашел наиболее интересными/информативными (курс готовился более года).

Программа курса
Материалы: «Разное»
Материалы: Object Oriented Programming in Scala
Материалы: Functional Programming in Scala
Материалы: Higher kinded types
Материалы: Parser combinators
Материалы: Metaprogramming / Reflection
Материалы: Metaprogramming / Macroses
Материалы: Scalaz
Материалы: Netty
Материалы: Akka
Материалы: Finagle
Материалы: Zookeeper
Материалы: Использование FP в финансовой отрасли


Программа курса



Спецкурс по Scala ставит своими целями
1. Глубоко изучить язык, включая такие «темные уголки» как macroses, path dependent types, generics of higher kind. Научиться создавать внутренние и внешние DSL. разобраться, почему в финансовой отрасли так популярны функциональные языки программирования.
2. Разобраться, почему при написании кода на функциональных языках программирования (и на Scala в частности) часто используют математические библиотеки обращающиеся к алгебре и теории категорий.
3. Посмотреть, почему современные стартапы (типа Twitter и LinkedIn) зачастую пишут свою инфраструктуру на Scala.

Спецкурс стартует 27 февраля 2015 года и состоит из 16 вебинаров по 2-2.5 часа. Длительность 3 месяца (1-2 занятия в неделю). Все лекции записываются на видео и предоставляются слушателям. Вся необходимая литература предоставляется в электронном виде. Я отвечаю на вопросы как в ходе вебинаров, так и в остальное время. Вы имеете возможность общаться с 15-20 другими слушателями, которые параллельно изучают Scala.

  • Модуль #1 (4 лекции): Базовая Scala
    Задача модуля — рассмотреть синтаксис и пути решения «бытовых» задач на Scala
    • «Разное»
      • Local Type Inference, unified types
      • Structural types, tuples
      • Generics: variance, upper/lower bounds, existential types
      • Lazy values, DelayedInit trait, App / Application
      • Implicits, view, view bounds
      • Sequence сomprehensions
      • Annotations, Exceptions
      • Work with XML
      • Scala’s Collections Library, Arrays

    • Object Oriented Programming
      • Classes, objects, traits
      • Type members, abstract types
      • Explicitly Typed Self References
      • Mixin class composition, compound types, hierarchy linearization
      • Cake Pattern

    • Functional Programming
      • Functional types, anonymous functions, nested functions, curring, partial application
      • Methods / Functions, Operators (prefix, infix, postfix; associativity), бесскобочная + бесточечная запись
      • Call-by-name / call-by-value, named and default params
      • Pattern matching, case classes, extractor objects


  • Модуль #2 (4 лекции): Продвинутая Scala
    Задача модуля — детально рассмотреть возможности Scala, которых нет в Java.
    • Dependent Types
    • Higher kinded types
    • Parser combinators
    • Metaprogramming = Reflection + Macros

  • Модуль #3 (4 лекции): Type-acrobatic libraries in Scala
    Задача модуля рассмотреть наиболее продвинутые библиотеки (в смысле использования системы типов и возможностей языка), как они написаны, что на них можно сделать.
    • Scalaz — немного теории категорий (монада, апликативный функтор, катаморфизм, ...)
    • Shapeless — a type class and dependent type based generic programming library
    • Algebird — или как в Twitter используют алгебру (моноид, группа, полукольцо, ...)

  • Модуль #4 (4 лекции): Многопоточное, сетевое и распределенное программирование
    Задача модуля рассмотреть наиболее популярные для JVM сетевые библиотеки, которые чаще всего являются «строительными блоками» больших распределенных систем. Разобраться, почему Twitter пишут на Scala.
    • Netty
    • Akka
    • Finagle
    • Zookeeper




Материалы: «Разное»



Вводные статьи по Scala


Данные статьи представляют собой краткие обзоры языка (15-20 страниц). Носят скорее идеологический/исторический характер — как сам автор (Одерский) видит свое детище, что он считает самым важным/отличительным/характерным.


Scala Style Guide




Основные статьи по Scala



Данные статьи освещают и проясняют основные характеристики языка.

  • «Scalable Component Abstractions», Odersky +…. We identify three programming language abstractions for the construction of reusable components: abstract type members, explicit selftypes and modular mixin composition. Together, these abstractions enable us to transform an arbitrary assembly of static program parts with hard references between them into a system of reusable components.… We demonstrate this approach in two case studies, a subject/observer framework and a compiler front-end.
  • «Type classes as objects and implicits», Odersky +…, Type classes were originally developed in Haskell as a disciplined alternative to ad-hoc polymorphism. Type classes have been shown to provide a type-safe solution to important challenges in software engineering and programming languages such as, for example, retroactive extension of programs. They are also recognized as a good mechanism for concept-based generic programming and, more recently, have evolved into a mechanism for type-level computation. This paper presents a lightweight approach to type classes in object-oriented (OO) languages with generics using the CONCEPT pattern and implicits (a type-directed implicit parameter passing mechanism).
  • «Matching Objects With Patterns», Odersky + ..., Pattern Matching во всей красе с Case classes / Extractors + сравнение с более классическими решениями (Visitor, Type-Test/Type-Cast, ...)


Курсы/подборки по Scala



Охват материала на небольшую книгу, но не книги. От «классиков».


Да, сама Coursera написана на Scala.

Книги



На рынке присутствует большое количество книг (порядка 20) по Scala, но мне в наибольшей степени понравились следующие 4
  • «Programming in Scala. 2ed» — книга от Одерского, классика, обязательна к прочтению
  • «Scala for the Impatient» — товарищ Хорстман и тут успел. Если Вам понравился его двухтомник по Java, возможно, стоит попробовать и это
  • «Scala in Depth» — хороший охват: от основ до продвинутых моментов
  • «DSLs in Action» — как реализовывать свои DSL на Scala



Материалы: Object Oriented Programming in Scala


  • «Independently Extensible Solutions to the Expression Problem», Odersky +…. Предлагается Scala-решение для «классической» Expression Problem. Частично решениями этой проблемы являются наследование (расширение сущностей) и шаблон Visitor (расширение операций), однако Одерский решает более интересную проблему — компоновка независимых расширений и сущностей и операций одновременно.
  • «Scala's Selfless Trait Pattern», Bill Venners — просто именованный шаблон работы с наследование в Scala
  • «Scala's Stackable Trait Pattern», Bill Venners — просто именованный шаблон работы с наследование в Scala



Материалы: Functional Programming in Scala


«Functional Programming in Scala» — сильная книга от одного из контрибюторов в Scalaz.


Материалы: Higher kinded types


  • «Fighting Bit Rot with Types», Odersky +… — описан рефакторинг коллекций Scala для версии 2.8 с хорошим погружением в higher-kind types, implicit parameters и implicit conversions



Материалы: Parser combinators



В Scala включен пакет (scala.util.parsing), который предоставляет инструменты для описания грамматики External DSL на Scala в формате близком к EBNF. Т.е. это «внутренний DSL» для создания «внешних DSL».

In Scala, parsers are implemented as monads — hence defining combinators for parsers are just monadic transformations implementing sequencing, alternation or any other composition operations.

В ряде предметных областей можно строить API в виде неких примитивных элементов (в данном случае парсеров) и способов комбинирования этих элементов определенным образом (комбинаторы). В данном случае в самом ядре языка есть все необходимое для построение внешних DSL.




Материалы: Metaprogramming / Reflection


A particularly interesting aspect of macros is that they are based on the same API used also for Scala’s runtime reflection, provided in package scala.reflect.api. This enables the sharing of generic code between macros and implementations that utilize runtime reflection.

Until 2.10, Scala has not had any reflection capabilities of its own. Instead, one could use part of the Java reflection API, namely that dealing with providing the ability to dynamically inspect classes and objects and access their members. However, many Scala-specific elements are unrecoverable under standalone Java reflection, which only exposes Java elements (no functions, no traits) and types (no existential, higher-kinded, path-dependent and abstract types). In addition, Java reflection is also unable to recover runtime type info of Java types that are generic at compile-time; a restriction that carried through to runtime reflection on generic types in Scala.

In Scala 2.10, a new reflection library was introduced not only to address the shortcomings of Java’s runtime reflection on Scala-specific and generic types, but to also add a more powerful toolkit of general reflective capabilities to Scala.… with full-featured runtime reflection for Scala types and generics…



Материалы: Metaprogramming / Macroses


A particularly interesting aspect of macros is that they are based on the same API used also for Scala’s runtime reflection, provided in package scala.reflect.api. This enables the sharing of generic code between macros and implementations that utilize runtime reflection.

Our flavor of macros is reminiscent of Lisp macros, adapted to incorporate type safety and rich syntax. Unlike infamous C/C++ preprocessor macros, Scala macros: 1) are written in full-fledged Scala, 2) work with expression trees, not with raw strings, 3) cannot change syntax of Scala. [here]

Macros are functions that are called by the compiler during compilation. Within these functions the programmer has access to compiler APIs. For example, it is possible to generate, analyze and typecheck code. You can learn more about macros from documentation. [here]

Def macros are shipped as an experimental feature of Scala since version 2.10.0. A subset of def macros, pending a thorough specification, is tentatively scheduled to become stable in one of the future versions of Scala.

Experimental feature — Also note that macros are considered an experimental and advanced feature, so in order to write macros you need to enable them. Do that either with import scala.language.experimental.macros on per-file basis or with -language:experimental.macros (providing a compiler switch) on per-compilation basis. Your users, however, don’t need to enable anything — macros look like normal methods and can be used as normal methods, without any compiler switches or additional configurations.



Материалы: Scalaz





Материалы: Netty


Netty — an asynchronious and event-driven network application framework for rapid development of maintanable high performance protocol servers and clients. Netty — это de fakto стандарт для использования java.net.*, NIO и NIO.2 (Akka и Finagle используют «под капотом» Netty, Zookeeper напрямую NIO/NIO.2). Хотя можно и напрямую реализовывать шаблоны асинхронной обработки сообщений Reactor / Proactor / Asynchronous Completion Token / Acceptor-Connector однако это сопряжено с большим количеством шаблонного кода и затенению функционала предметной области. Преимуществом Netty является как декларативность кода, так и то, что библиотека представляет собой конструктор протоколов (http, ftp, smtp, websockets, ...).




Материалы: Akka


Akka — de facto стандарт framework-а для многопоточных и распределенных архитектур на основе акторов для JVM. Начиная c версии Scala 2.10.0 Akka вытеснила «родную» реализация акторов.



Материалы: Finagle


Finagle — A Protocol-Agnostic extensible RPC System for the JVM, used to construct high-concurrency servers. Написанная и используемая в twitter.com. Основной принцип — «We must program locally, communicate globally». Часть Twitter-стека (вместе с Ostrich, Zipkin, Mesos, Iago, ZooKeeper, Scalding). Finagle включает в себя функции балансировки нагрузки, connection pooling, вызов с timeout-ом, мониторинг, сбор статистики.



Материалы: Zookeeper


Zookeeper — fail-safe централизованный сервис для управления конфигурационной информацией, именованием, распределенной синхронизации и других групповых сервисов, составная часть Twitter-стека. Может быть использован для созданий базовых структур данных (кластерных) — очередей, блокировок, барьеров. Подходит для таких распределенных алгоритмов как two-phase-commit, выборы лидера и других.



Материалы: Использование FP в финансовой отрасли



По ряду причин (возможность описания предметной области на языке комбинаторов) функциональные языки программирования любят использовать в финансовой отрасли, что создает спрос на «функциональщиков» в Нью-Йорке и Лондоне.

  • «Composing Contracts: An Adventure in Financial Engineering», Simon Peyton Jones +… — базовая статья от автора Haskell о представление финансовых контрактов на Haskell. «We introduce a combinator library that allows us to describe such contracts precisely, and a compositional denotational semantics that says what such contracts are worth. We sketch an implementation of our combinator library in Haskell. Interestingly, lazy evaluation plays a crucial role». «The finance industry has an enormous vocabulary of jargon for typical combinations of financial contracts (swaps, futures, caps, oors, swaptions, spreads, straddles, captions, European options, American options, ...the list goes on)». «Our combinators can be used to describe a contract, but we also want to process a contract. Notably, we want to be able to find the value of a contract. In Section 4 we describe how to give an abstract valuation semantics to our combinators. A fundamentally-important property of this semantics is that it is compositional; that is, the value of a compound contract is given by combining the values of its sub-contracts.»
  • «Commercial Uses: Going functional on exotic trades» — описание DSL используемого в Barclays для работы с финансовыми инструментами (Haskell). «The Functional Payout Framework (fpf) is a Haskell application that uses an embedded domain-specific functional language to represent and process exotic financial derivatives. Whereas scripting languages for pricing exotic derivatives are common in banking, fpf uses multiple interpretations to not only price such trades, but also to analyse the scripts to provide lifecycle support and more»
  • «Scala at EDF Trading. Implementing a Domain-Specific Language for Derivative Pricing with Scala.» — «DIESEL is a language for representing energy derivatives to facilitate Monte Carlo pricing and analytics. The DSL consists of a combinator parser libary and algebraic data types with case classes.»
  • «Compositional specification of commercial contracts»
  • «An Algebraic Specification of a Language for Describing Financial Products» — «We report on the use of formal methods and supporting tools during the development of a language applied in a banking environment. This language, called RISLA, is used to define the nature of the interest products offered by a bank. A RISLA description fixes the cash flows (amounts of money coming in or going out on particular dates) resulting from a product…. The language has been developed with the use of algebraic specifications, the role of which is discussed.»
  • «Domain-Specific Languages versus Object-Oriented Frameworks: A Financial Engineering Case Study» — «The use of a domain-specific language can help to develop readable and maintainable applications in that domain with little effort. Alternatively, the same aims can be achieved by setting up an object-oriented framework. For the domain of financial engineering, independently both an objectoriented framework and a domain-specific language have been developed. We use this opportunity to contrast these two, to highlight the differences and to discuss opportunities for mutual benefits.»
  • «Adventures in financial and software engineering»
  • «Financial Domain-Specific Language Listing — большая подборка API / DSL для работы с финансами


P.S. На любые вопросы с удовольствием ответим по
skype: GolovachCourses
email: GolovachCourses@gmail.com

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Какую технологию / какой фреймворк Вы бы хотели изучить / добавить в резюме?

GolovachCourses
35,00
Компания
Поделиться публикацией

Похожие публикации

Комментарии 32

    0
    Как то очень много ссылок. А где посмотреть цены?
      0
      Курс стоит — 395$.
      При оплате группой предусмотрены скидки
      2 человека — 695$
      3 человека — 995$
      Если группа больше — пишите в личку.

      Ссылок много, так как я при переходе на Scala и при написании курса проанализировал множество источников.
      +13
      Расскажите, пожалуйста, о проектах на Scala, в которых вы участвовали. И, если это возможно, какие из частей вашего курса реально соприкасаются с этими проектами и каким образом.
        +4
        да, хотелось бы узнать подробнее об опыте на scala.
          0
          1. Опыта промышленной разработки на Scala у меня нет.
          2. Опыт использования в промышленных проектах на Java библиотек Akka, Finagle, Netty, Zookeeper — 4+ года.
          3. Было бы лучше, если бы преподавал человек с большим опытом на Scala?
          Да, было бы лучше.
          4. Какое я имею моральное право преподавать курс по Scala?
          Этот курс более академический, чем практический. Основан на исследованиях сложных моментов в языке (path dependent types, macroses, generics of higher kind, reflection api, ...) и на возможностях популярных «сложных» библиотек (scalaz, shapeless, algebird). Для эффективности курса такого рода, по моему мнению, важны проработка программы и подбор характерных примеров.
          5. Не считаю ли я, что курс был бы круче, если бы его преподавал, скажем, Бурмако?
          Скорее всего. Как только он начнет читать курсы по Scala сразу же к нему запишусь.
            +6
            Собственно на этом тему платных (и не дешевых) курсов по Scala можно заканчивать…
              +2
              круто, человек не имеющий практического опыта разработки на скале, организовал платные курсы за 400 баксов с человека. Это ни в какие ворота.

              удачи.
          0
          Можно добавить в список ScalaCheck.
            0
            Отдельное огромное вам спасибо за этот подраздел «Использование FP в финансовой отрасли». Не подскажите где еще можно почерпнуть материала по теме?
              0
              Вот курс есть: www.coursera.org/course/compfinance
              Там на R, но это не суть.
              Плюс к этому можно Quantitative Finance Пола Вилмотта добавить.
              0
              Интересно еще услышать мнение человека, который разобрался в Scala, о необходимости сборки библиотек под разные версии компилятора (2.10, 2.11 и т.п.), когда поддерживаемая версия Scala пишется прямо в артефакт. Кажется, что усложнение выкладки своих проектов для разработчика — это одна из проблем современной Scala не говоря уже о неинтуитивном sbt.
                +2
                А что более интуитивно?
                После make мне sbt казалось запутанным и негибким. Но увидев Maven я начал радоваться sbt…
                  0
                  А что более интуитивно?

                  Leiningen, например. Та же JVM, та же Maven-like система, но при этом устанавливается и осваивается за 20 минут.
                    +1
                    Ох уж мне эти осваивальщики за 20 минут… )
                    Вот так прямо за 20 минут можно поставить и изучить все 100% возможностей?

                      +1
                      А вы часто используете 100% возможностей билд-системы?
                      Не знаю как вам, но мне в 95% случаев от билд-системы нужно:

                      1. Управление зависимостями. Желательно централизованное.
                      2. Запуск тестов.
                      3. Сбор артефакта/библиотеки.

                      Менее важно, но nice to have:

                      4. Возможность запускать некий «главный» класс или метод.
                      5. Возможность запускать REPL.
                      6. Возможность публиковать артефакт в общий централизованный репозиторий.

                      Ещё в 3% случаев мне бывают нужны профили (например, чтобы собирать для разных окружений), ну и совсем-совсем редко мне нужны какие-то не совсем стандартные плагины.

                      Leiningen для Clojure позволяет сделать указанные 6 пунктов максимально просто (за другими двумя придётся заглянуть в туториал). Python PIP/setuptools делает это по-своему, но тоже максимально просто. Примерно то же можно сказать и про Bundle в Ruby. R и Julia позволяют такие манипуляции вообще из коробки и без использования любых дополнительных средств.

                      Maven позволяет кастомизировать любую свою часть за счёт плагинов, которые часто нужно подключать и конфигурировать отдельно. SBT, по сравнению с ним, имеет значительную часть функциональности из коробки, но при этом использует свой набор операторов, определений и скрытых правил. Трудно сказать, какой подход лучше, но оба — Maven и SBT — заставляют меня вкладывать больше времени в изучение и/или использование.

                      Поэтому нет, за 20 минут я не изучу 100% возможностей системы, но этого мне будет достаточно, чтобы успешно использовать её в 95% случаев без углубления в туториалы и копи-паста из гугла.
                        +2
                        >Поэтому нет, за 20 минут я не изучу 100% возможностей системы, но этого мне будет достаточно, чтобы успешно использовать её в 95% случаев без углубления в туториалы и копи-паста из гугла.

                        Про Maven, Gradle и SBT все ровно тоже самое можно сказать.
                        Все самое необходимое давно отлажено и не требудет месяцев изучения.
                        В мавене только конфиг подлиннее будет за счет многословности xml.

                        Так что этот выпендреж с «20мин» про кложу — не канает)
                        Ибо, по сути, не дает каких-то особых преимуществ после Gradle и SBT.
                        Особенно учитывая:
                        >трудно сказать, какой подход лучше, но оба — Maven и SBT — заставляют меня вкладывать больше времени в изучение и/или использование.

                        Или вы правда думаете, что люди рождаются со знанием кложи?
                          0
                          Скажите, вам правда интересно, почему я считаю, что Maven и SBT менее интуитивны, чем Leiningen, Setuptools и т.д., или вы просто хотите пофлеймить в защиту своих любимых инструментов? Если первое, давайте продолжим, если второе, то нет, спасибо, разводить религиозные споры на ровном месте не собираюсь.
                            +1
                            Открою страшную тайну. У меня нет «любимых инструментов».
                            Предпочитаю Gradle, но никаких проблем с SBT и Maven не испытваю.
                            Не вижу никакой «неинтуитивности» ни в SBT ни в Gradle.
                            Мавен тут особняком, ибо он все таки совсем другой.
                            Да и вообще понятие «интуитивность» тут как-то странно звучит. Ибо какая может быть эта самая интуитивность при отсутствии знания предмета (в данном случае языков Groovy, Scala, Clojure)?
                            А при их наличии все выглядит нормально.
                            У меня есть достаточный опыт Gradle и SBT.
                            Посмотрел на Leiningen, не увидел каких-то принципиальных отличий.
                            Ну если конечно не считать, что скобки добавляют какой-то особенной интуитивности коду)

                            Если не учитывать варианты типа «Вот тут мы пишем скобочку с двоеточием и это офигенно интуитивно» есть какие реальные преимущества у тогоже Leiningen?
                              +1
                              Ок, давайте сделаем простой проект и посмотрим, чего это нам стоит с каждым из инструментом. Сценарий простой и включает команды, которые нужно делать практически для каждого проекта и часто по несколько раз:

                              1. Создать проект с одним или несколькими классами и функцией main.
                              2. Указать завимую библиотеку (пусть будет Lucene).
                              3. Запустить проект.
                              4. Запустить тесты.
                              5. Собрать jar.
                              6. Собрать «fat» jar.
                              7. Запустить REPL с зависимости.

                              Факультатив:

                              8. Установить в локальный репозиторий, чтобы использовать в других проектах.
                              9. Опубликовать в централизованный репозиторий, чтобы поделиться с другом.

                              Leiningen
                              — 1. `lein new example`. Эта команда сгенерирует структуру проекта и project.clj.
                              2. Добавляем `[org.apache.lucene/lucene-core «5.0.0»]` в секцию :dependencies файла project.clj. Если что, квадратные скобки — это вектор значений, вектора знают все, кто хоть раз писал на Clojure.
                              3. Указываем главный класс в project.clj, запускаем `lein run`.
                              4. `lein test`.
                              5. `lein jar`.
                              6. `lein uberjar`.
                              7. `lein repl`.
                              8. `lein install`.
                              9. `lein deploy`.

                              Не уверен, что что-нибудь из этого можно сделать проще или меньшим количеством команд. Время выполнения теста (вместе с установкой Leiningen) — 6 минут.

                              Maven
                              — 1. Тут у нас есть два варианта. Если мы до этого уже что-то слышали про Maven, мы можем создать структуру директорий и pom.xml самостоятельно, или скопировать из другого проекта. Если никогда ни с чем таким не встречались, лезем на maven.apache.org и обнаруживаем такую инструкцию:

                              mvn archetype:generate -DgroupId=com.mycompany.app -DartifactId=my-app -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false
                              


                              Сразу возникает вопрос, а что такое архетип, группа, артефакт, и почему все слова начинаются с -D? Объяснений на сайте, кстати, нет. Ну да ладно, мы умеем гуглить, разобрались.
                              2. Тут всё просто:
                                <dependency>
                              	<group Id>org.apache.lucene</groupId>
                              	<artifactId>lucene-core</artifactId>
                              	<version>5.0.0</version>
                                < /dependency>
                              

                              3. А тут внезапно оказывается, что чтобы запускать классы Maven-у нужен плагин.
                              4. `mvn test` — снова просто.
                              5. `mvn package`. Если только вы не пытаетесь пропустить тесты (для сраванения, `lein jar` не запускал тесты), в этом случае нужно указать специальную опцию — `-Dmaven.skip.test=true`. Или `-Dmaven.test.skip=true`? А ещё можно `-DskipTests=true` или как-то так. Пока ещё ни один джавист мне сходу и без колебаний не назвал правильной опции.
                              6. Снова нужен плагин.
                              7. Не релевантно, пропускаем.
                              8. `mvn install`
                              9. `mvn deploy`

                              SBT
                              — Вообще SBT заслуживает особого внимания в части интутивности. Я сделал с десяток проектов с ним, но для меня до сих пор загадка, что же из себя представляет build.sbt. Это и не файл конфигурации — в нём мы оперируем Scala командами, но это и не файл с исходным кодом — инструкции выполняются не по порядку, часто требуют пустых строк и т.д. `:=` кажется присваиванием значения параметру пока вдруг не увидишь `foo in Compile := ...`, а замена дефолтных параметров через `param / «non-default-value»` — это вообще огонь. Но всё по-порядку.

                              1. Никаких специальных команд для генерации проекта, всё ручками.
                              2. `libraryDependencies += «org.apache.lucene» % «lucene-core» % «5.0.0»`. Проценты кажутся разделителями, пока не увидишь "%%" и не поймёшь, что не всё так просто.
                              3. `sbt run`. Стоп, но я ведь ещё не указал main класс! А вот чтобы выбрать нужный класс среди нескольких внезапно нужно писать не просто `mainClass := ...`, а `mainClass in (Compile, run) := ...`. Примерно после этого открытия я перестал пытаться понять SBT.
                              4. `sbt test`.
                              5. `sbt package`. Пропустить тесты можно через `test in assembly := {}`. Очевидно.
                              6. Плагины — наше всё!
                              7. Ну хоть тут без неожиданностей. `sbt console`.
                              8. `sbt publish`.
                              9. Единственный способ опубликовать свой артефакт в SBT — это прописать настройки Maven-а :)

                              В общем, если вам всё это кажется простым и интуитивным, окей — на вкус и цвет все фломастеры разные. Лично я уже давно перестал рассчитывать на SBT/Maven в качестве «помощников», аналогичных тем, что есть у меня в других языках.
                                +1
                                Во первых, спасибо за развернутый ответ.
                                Теперь понятно что и как вы сравниваете.

                                >В общем, если вам всё это кажется простым и интуитивным

                                Я подхожу с другой стороны)
                                Вообще не заморачиваюсь по таким поводам. Сборка проекта пишется один раз (условно). Это не код проекта на тысячи строк с постоянными изменениями.
                                Принципиальное отличие для меня всего одно. Maven и все остальные. Ну вроде как «xml» vs «нормальный код» в скриптах сборки.

                                build.sbt не использую. Все через Build.scala. Простым кодом.

                                Поэтому… надо писать не просто `mainClass := ...`, а `mainClass in (Compile, run) := ...`?
                                Да и фиг с ним, напишу как надо не переломаюсь. Ибо давно перестал пытаться угадывать методы АПИ в используемых либах. Порою кажется что их разработчики покуривают что-то серьезное)
                                Не стоит сборочные скрипты того, на проекте есть очень много других мест, на которые стоит тратить энергию.

                                Публиковать через Maven… И что такого критического в этом? Один фиг все зависимости в JVM мире через maven идут. Ну не очень красиво… ну и что? Позже сделают обертку по красивее, как у других. Совершенно не критично. Да и публикация в централизованный репозиторий далеко не самая частая операция.
                                  0
                                  Собственно да, вопрос был в том, насколько это интуитивно. А так-то да, работать можно вполне успешно :)
                                  0
                                  попробуйте activator вместо sbt
                                    0
                                    Я так понимаю, что activator — это просто обёртка вокруг sbt для более простой работы с Play! / Akka?
                      +2
                      Как раз Maven имеет простую модель работы и простой синтаксис XML. А вот на его код лучше не смотреть ибо там внутри Plexus. :) Но меня скорее интересует ваше мнение про сборку под разные версии Scala.
                      0
                      Как раз продолжительно мучаю переход нашего билда с maven на SBT. Соглашусь, что он не интуитивен.
                      0
                      По моему были бы востребованы курсы по технологиям, типа ActiveMQ, Camel. Особенно вместе со Scala+Akka.
                        +1
                        автор мы вот все еще ждем вашего ответа на этот вопрос habrahabr.ru/company/golovachcourses/blog/251239/#comment_8297141
                        вы же заходите на сайт регулярно, ответьте пожалуйста
                          +3
                          автор считает, что достаточно написать много раз в тексте «Я» и все поймут, что курсы крутые и они стоят 400 баксов.
                            0
                            Это, скорее всего, издержки того, что в моей практике устная речь зачастую преобладает над письменной.
                            Согласен с тем, что от таких «артефактов» стоит избавляться.
                          0
                          Плюс Вам в карму за выложенный материал. Но Скалу учить можно и с Одерским на Курсере, а дальше только писать живые проекты.
                          Кстати, зря Вы Spray.io обделили своим вниманием. Замечательная функциональная http библиотека, кстати стандарт в следующей версии Play.
                          +1
                          Автор принялся рассылать письма и подписывается Анной, хотя в обратном адресе написано Иван.
                          Если вы вдруг хотите за деньги коллективно почитать другие документации, то на сайте есть больше предложений:
                          www.golovachcourses.com/

                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                          Самое читаемое