Комментарии 32
Как то очень много ссылок. А где посмотреть цены?
Расскажите, пожалуйста, о проектах на Scala, в которых вы участвовали. И, если это возможно, какие из частей вашего курса реально соприкасаются с этими проектами и каким образом.
да, хотелось бы узнать подробнее об опыте на scala.
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 сразу же к нему запишусь.
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 сразу же к нему запишусь.
Можно добавить в список ScalaCheck.
Отдельное огромное вам спасибо за этот подраздел «Использование FP в финансовой отрасли». Не подскажите где еще можно почерпнуть материала по теме?
Вот курс есть: www.coursera.org/course/compfinance
Там на R, но это не суть.
Плюс к этому можно Quantitative Finance Пола Вилмотта добавить.
Там на R, но это не суть.
Плюс к этому можно Quantitative Finance Пола Вилмотта добавить.
Интересно еще услышать мнение человека, который разобрался в Scala, о необходимости сборки библиотек под разные версии компилятора (2.10, 2.11 и т.п.), когда поддерживаемая версия Scala пишется прямо в артефакт. Кажется, что усложнение выкладки своих проектов для разработчика — это одна из проблем современной Scala не говоря уже о неинтуитивном sbt.
А что более интуитивно?
После make мне sbt казалось запутанным и негибким. Но увидев Maven я начал радоваться sbt…
После make мне sbt казалось запутанным и негибким. Но увидев Maven я начал радоваться sbt…
А что более интуитивно?
Leiningen, например. Та же JVM, та же Maven-like система, но при этом устанавливается и осваивается за 20 минут.
Ох уж мне эти осваивальщики за 20 минут… )
Вот так прямо за 20 минут можно поставить и изучить все 100% возможностей?
Вот так прямо за 20 минут можно поставить и изучить все 100% возможностей?
А вы часто используете 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% случаев без углубления в туториалы и копи-паста из гугла.
Не знаю как вам, но мне в 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% случаев без углубления в туториалы и копи-паста из гугла.
>Поэтому нет, за 20 минут я не изучу 100% возможностей системы, но этого мне будет достаточно, чтобы успешно использовать её в 95% случаев без углубления в туториалы и копи-паста из гугла.
Про Maven, Gradle и SBT все ровно тоже самое можно сказать.
Все самое необходимое давно отлажено и не требудет месяцев изучения.
В мавене только конфиг подлиннее будет за счет многословности xml.
Так что этот выпендреж с «20мин» про кложу — не канает)
Ибо, по сути, не дает каких-то особых преимуществ после Gradle и SBT.
Особенно учитывая:
>трудно сказать, какой подход лучше, но оба — Maven и SBT — заставляют меня вкладывать больше времени в изучение и/или использование.
Или вы правда думаете, что люди рождаются со знанием кложи?
Про Maven, Gradle и SBT все ровно тоже самое можно сказать.
Все самое необходимое давно отлажено и не требудет месяцев изучения.
В мавене только конфиг подлиннее будет за счет многословности xml.
Так что этот выпендреж с «20мин» про кложу — не канает)
Ибо, по сути, не дает каких-то особых преимуществ после Gradle и SBT.
Особенно учитывая:
>трудно сказать, какой подход лучше, но оба — Maven и SBT — заставляют меня вкладывать больше времени в изучение и/или использование.
Или вы правда думаете, что люди рождаются со знанием кложи?
Скажите, вам правда интересно, почему я считаю, что Maven и SBT менее интуитивны, чем Leiningen, Setuptools и т.д., или вы просто хотите пофлеймить в защиту своих любимых инструментов? Если первое, давайте продолжим, если второе, то нет, спасибо, разводить религиозные споры на ровном месте не собираюсь.
Открою страшную тайну. У меня нет «любимых инструментов».
Предпочитаю Gradle, но никаких проблем с SBT и Maven не испытваю.
Не вижу никакой «неинтуитивности» ни в SBT ни в Gradle.
Мавен тут особняком, ибо он все таки совсем другой.
Да и вообще понятие «интуитивность» тут как-то странно звучит. Ибо какая может быть эта самая интуитивность при отсутствии знания предмета (в данном случае языков Groovy, Scala, Clojure)?
А при их наличии все выглядит нормально.
У меня есть достаточный опыт Gradle и SBT.
Посмотрел на Leiningen, не увидел каких-то принципиальных отличий.
Ну если конечно не считать, что скобки добавляют какой-то особенной интуитивности коду)
Если не учитывать варианты типа «Вот тут мы пишем скобочку с двоеточием и это офигенно интуитивно» есть какие реальные преимущества у тогоже Leiningen?
Предпочитаю Gradle, но никаких проблем с SBT и Maven не испытваю.
Не вижу никакой «неинтуитивности» ни в SBT ни в Gradle.
Мавен тут особняком, ибо он все таки совсем другой.
Да и вообще понятие «интуитивность» тут как-то странно звучит. Ибо какая может быть эта самая интуитивность при отсутствии знания предмета (в данном случае языков Groovy, Scala, Clojure)?
А при их наличии все выглядит нормально.
У меня есть достаточный опыт Gradle и SBT.
Посмотрел на Leiningen, не увидел каких-то принципиальных отличий.
Ну если конечно не считать, что скобки добавляют какой-то особенной интуитивности коду)
Если не учитывать варианты типа «Вот тут мы пишем скобочку с двоеточием и это офигенно интуитивно» есть какие реальные преимущества у тогоже Leiningen?
Ок, давайте сделаем простой проект и посмотрим, чего это нам стоит с каждым из инструментом. Сценарий простой и включает команды, которые нужно делать практически для каждого проекта и часто по несколько раз:
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 и обнаруживаем такую инструкцию:
Сразу возникает вопрос, а что такое архетип, группа, артефакт, и почему все слова начинаются с -D? Объяснений на сайте, кстати, нет. Ну да ладно, мы умеем гуглить, разобрались.
2. Тут всё просто:
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. Создать проект с одним или несколькими классами и функцией 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 в качестве «помощников», аналогичных тем, что есть у меня в других языках.
Во первых, спасибо за развернутый ответ.
Теперь понятно что и как вы сравниваете.
>В общем, если вам всё это кажется простым и интуитивным
Я подхожу с другой стороны)
Вообще не заморачиваюсь по таким поводам. Сборка проекта пишется один раз (условно). Это не код проекта на тысячи строк с постоянными изменениями.
Принципиальное отличие для меня всего одно. Maven и все остальные. Ну вроде как «xml» vs «нормальный код» в скриптах сборки.
build.sbt не использую. Все через Build.scala. Простым кодом.
Поэтому… надо писать не просто `mainClass := ...`, а `mainClass in (Compile, run) := ...`?
Да и фиг с ним, напишу как надо не переломаюсь. Ибо давно перестал пытаться угадывать методы АПИ в используемых либах. Порою кажется что их разработчики покуривают что-то серьезное)
Не стоит сборочные скрипты того, на проекте есть очень много других мест, на которые стоит тратить энергию.
Публиковать через Maven… И что такого критического в этом? Один фиг все зависимости в JVM мире через maven идут. Ну не очень красиво… ну и что? Позже сделают обертку по красивее, как у других. Совершенно не критично. Да и публикация в централизованный репозиторий далеко не самая частая операция.
Теперь понятно что и как вы сравниваете.
>В общем, если вам всё это кажется простым и интуитивным
Я подхожу с другой стороны)
Вообще не заморачиваюсь по таким поводам. Сборка проекта пишется один раз (условно). Это не код проекта на тысячи строк с постоянными изменениями.
Принципиальное отличие для меня всего одно. Maven и все остальные. Ну вроде как «xml» vs «нормальный код» в скриптах сборки.
build.sbt не использую. Все через Build.scala. Простым кодом.
Поэтому… надо писать не просто `mainClass := ...`, а `mainClass in (Compile, run) := ...`?
Да и фиг с ним, напишу как надо не переломаюсь. Ибо давно перестал пытаться угадывать методы АПИ в используемых либах. Порою кажется что их разработчики покуривают что-то серьезное)
Не стоит сборочные скрипты того, на проекте есть очень много других мест, на которые стоит тратить энергию.
Публиковать через Maven… И что такого критического в этом? Один фиг все зависимости в JVM мире через maven идут. Ну не очень красиво… ну и что? Позже сделают обертку по красивее, как у других. Совершенно не критично. Да и публикация в централизованный репозиторий далеко не самая частая операция.
попробуйте activator вместо sbt
Как раз Maven имеет простую модель работы и простой синтаксис XML. А вот на его код лучше не смотреть ибо там внутри Plexus. :) Но меня скорее интересует ваше мнение про сборку под разные версии Scala.
Как раз продолжительно мучаю переход нашего билда с maven на SBT. Соглашусь, что он не интуитивен.
По моему были бы востребованы курсы по технологиям, типа ActiveMQ, Camel. Особенно вместе со Scala+Akka.
автор мы вот все еще ждем вашего ответа на этот вопрос habrahabr.ru/company/golovachcourses/blog/251239/#comment_8297141
вы же заходите на сайт регулярно, ответьте пожалуйста
вы же заходите на сайт регулярно, ответьте пожалуйста
Плюс Вам в карму за выложенный материал. Но Скалу учить можно и с Одерским на Курсере, а дальше только писать живые проекты.
Кстати, зря Вы Spray.io обделили своим вниманием. Замечательная функциональная http библиотека, кстати стандарт в следующей версии Play.
Кстати, зря Вы Spray.io обделили своим вниманием. Замечательная функциональная http библиотека, кстати стандарт в следующей версии Play.
У Мартина в том курсе только основы. По сути, весь его курс в этой ( ru.wikibooks.org/wiki/Scala_%D0%B2_%D0%BF%D1%80%D0%B8%D0%BC%D0%B5%D1%80%D0%B0%D1%85 ) статье. А хочется курсы послушать от человека с промышленным опытом использования той или иной библиотеки.
Автор принялся рассылать письма и подписывается Анной, хотя в обратном адресе написано Иван.
Если вы вдруг хотите за деньги коллективно почитать другие документации, то на сайте есть больше предложений:
www.golovachcourses.com/
Если вы вдруг хотите за деньги коллективно почитать другие документации, то на сайте есть больше предложений:
www.golovachcourses.com/
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Программа курса и материалы по Scala