ReactJS, TypeScript, Micro FrontendsReact fwdays | 27 березня. Долучайся!
×Закрыть

Риски первого проекта на scala и способы их минимизации


Ниже — конспект моего доклада на первой встрече группы пользователей scala в Украине.
Вторая встреча состоится 14 января dou.ua/calendar/1181

Добрый день уважаемые господа. Перед тем как перейти к основной части повествования, несколько общих замечаний: этот рассказ будет о сложностях при разработке на scala и я боюсь, что он может быть воспринят критиками как еще один YASTCA «yet another scala too complex article». Это не так — любой язык предоставляет нам какой-то баланс возможностей и ограничений, а представление о том, что вот есть какая-то одна идеальная технология мне кажется наивным, это такая юношеская болезнь технологического фетишизма. И вот с одной стороны, я этим переболел уже давно, а с другой стороны — для меня scala неожиданно стала подобна серебряной пуле, позволяющей моей фирме с малыми силами конкурировать с большими организациями. Поэтому слушая этот рассказ о недостатках scala, не забывайте что для меня это не только набор проблем, но и серебрянная пуля ;)

Макроуровень:

Срединный путь в отсутствие колеи

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

Точно так же, с появлением scala, программиствам в поисках просветления не обязательно уходить в haskell, а можно делать нечто полезное для общества [троллинг, не принимайте всерьез ;)]. Казалось бы прекрасно, но — у нас нет колеи.

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

При этом стандартные соглашения о стиле кодирования действительно описывают только стиль и оставляют открытыми все семантические вопросы, среди которых:

  • Способы обработки ошибок — что мы предпочитаем делать — генерировать исключения или использовать Either (?)
  • Предпочтительные наборы коллекций — по умолчанию мы используем mutable или immutable варианты. (?)
  • Способы задания поведения. В scala их три (функции, trait-s использующиеся как java интерфейсы, структурные типы)
  • Спектр используемых инструментов — чего мы боимся, а чего — нет (?) (@cps, scalaz, views)

Поэтому в scala проекте о многих вещах нужно договариваться либо заранее, либо сразу после того, как возникли первые противоречия (второе мне нравится больше). Однако эти противоречия надо заметить.

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

Инфраструктура vs Функциональность

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

Поэтому имеет смысл делать свою реализацию Dimensions или общей XML сериализации только если это действительно необходимо.

Необычные кривые обучения

Еще одна «общая» неожиданность, которая может подстерегать проект — это нетривиальная кривая обучения. Мы привыкли к тому, что стандартная кривая обучения выглядит следующим образом:

Однако в scala есть очень много мест, где кривая обучения выглядит по-другому. Например так:

Пример — xml. Использовать XML литералы можно сразу, а вот что-бы сделать что-то сложное, необходимо изучать дизайн библиотеки, который далеко не самый интуитивный.
А кривая обучения некоторых пакетов (тот же lift) — вообще напоминает кривую Дирихле.

Ванная без ребенка

И последнее замечание «макроуровня» — если уж мы пошли на использование scala, то не использовать существующие высокоуровневые библиотеки доступа к данным или сериализации из-за их сложности — это тоже большая ошибка, так как продуктивность разработчика, использующего DSL со статической типизацией заметно выше, чем продуктивность разработчика отлаживающего генерацию строк запросов.

Микроуровень

Обработка ошибок: Either vs Exception.

Как мы знаем, в scala одновременно существует и идиома исключительных ситуаций, точно так же как она реализована и в других языках (то есть throw Exception) и идиома возврата специального типа Ether со следующим упрощенным определением:

sealed abstract class Either[+A,+B]
{
   def isLeft: Boolean
   def left : A
   def isRight: Boolean
   def right: A
   ….............
}
final case class Left[+A,+B)(a:A) extends Either[A,B] { .. }
final case class Right[+A,+B)(b:B) extends Either[A,B] { … }

Можно ли выработать какие-то универсальные правила, позволяющие сказать — когда обработку ошибок надо реализовывать с помощью Either, а когда — с помощью исключения?

Люди с бекграундом Haskell часто предпочитают вариант с Either, однако, на практике:
если мы взаимодействуем с java кодом, то использование Either не спасает нас от обработки исключений. В отличие от haskell, где наиболее распротраненный путь создания сложного из простого — это композиция функций, в scala часто используется просто последовательная запись. И из-за возможности обработки ошибок записывать (f; g; v) как (f.right map g).right map v - скорее усложнение чем упрощение. Вообще, языки с императивной семантикой нам бесптлатно дают монаду, которая называется «выполнение кода». Имеет ли смысл поверх этого делать еще один уровень интерпретации — вопрос неоднозначный. В моей практике — почти никогда.

Поэтому я бы рекомендовал следующую политику:

  • Стандартная обработка ошибок в scala — это в первую очередь исключительные ситуации (unchecked exception)
  • Either используется в тех случаях, когда нам надо обязательно надо обработать результат неудачной операции, то есть именно те случаи, когда в java мы бы использовали checked exceptions.

В случаях, когда мы работаем в транзакционном окружении есть формальный критерий различения Either/Exception: при обработке прерывания мы, как правило, откатываем транзакцию, при обработке Either — нет.

Еще одна проблема Either — отсутствие базовой левой части в стандартной библиотеке. То есть хотелось бы видеть нечто вроде:

case class Failure[V](v:V,ex:Option[Throwable])
{
  def this(v:V) = this(v,None);
  def this(v:V,ex:Throwable) = this(v,Some(ex));
}
implicit def toLeft[V,U](f:Failure[V]):Left[Failure[V],U]=Left(f);

в стандартной библиотеке.

Границы сред и ленивые вычисления

Еще одна часто встречаемая проблема, для которой в scala пока нет универсального приемлемого решения — контроль границы среды. К примеру, посмотрим на следующий фрагмент кода:

import org.squeryl._
..
import  collection.JavaConversions._
def  provideApiAsJavaList(tags:java.util.List[String]): java.util.List[Customer] =
{
  inTransaction {
      from(customers, contracts)(  (c,t)=>where((t.customerId===<a href="http://c.id" target="_blank">c.id</a>)
                                                            and
                                                           (t.tags in tags)
                                                        ) select ( c )) . toSeq
  }
}

Где тут ошибка ?

Ошибка возникает, если мы вызовем этот код вне контекста транзакции, так как запрос нам вернет объект типа Query[Customer] который «лениво» преобразуется в Seq[Customer] который так=же лениво преобразуется в java.util.List[Customer].
И итерация данных собственно начнется тогда, когда мы начнем чтение списка в java-коде. К тому времени транзакция уже завершиться, соответственно попытка чтения вызовет исключение

Можно ли предотвратить существование таких ошибок:

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

Вообще, идея для упрощения использование держать что-то в ThreadLocal и надеяться что этот контекст будет доступен всегда, она и для java-ы довольно рискованная, а для scala, где есть развитые методы нестандартной передачи управления, это вообще становится подводной миной, делая все операции передачи замыкания в неизвестный контекст потенциально опасными. Было бы логично рекомендовать авторам библиотек прямо передавать контекст (возможно с помощью неявных параметров) везде, где только возможно.

Неявное преобразование к типу общего назначения

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

implicit  def  s2i(s:String):Int = Integer.parseInt(x).intValue;
val x:Int = “5”;

В моем понимании, использование implicit оправданно в cледующих случаях:

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

  • если мы используем implicit для эмуляции extensions methods — то есть создаем специальный класс, в котором определяем дополнительные методы

  • если мы используем implicit как адаптор к какой-то бибилиотеки и импортируем эти преобразования только в своем слое взаимодействия
И случай когда использование implicit cкорее всего неоправданно:
  • когда на выходе «implicit» у нас класс общего назначения

Заключение

Надеюсь, что перечисленные здесь вещи, на которые стоит обратить внимание сделают процесс вхождения в scala более легким и предсказуемым, а код — простым и понятным. В целом, мне ситуация со scala очень напоминает С++ в 90-ых: сравнительно большой и сложный язык, кривой во многих местах, но дающий настолько мощный сдвиг мышления и повышения эффективности разработки, что инвестиции в обучение и обход потенциальных проблем заведомо окупаются с лихвой, так что сегодня разработка на «чистом C» стала уже маргинальным явлением.

👍НравитсяПонравилось0
В избранноеВ избранном0
Подписаться на автора
LinkedIn

Похожие статьи




Підписуйтесь: SoundCloud | Google Podcast | YouTube


67 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Хотелось бы, всетаки услышать про то, где искать скала программистов воще. И хороших в частности.

Да, в принципе там же, где и Java. Тем более плохих Scala-программистов практически не бывает.

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

Где искать компании, в которых используется Скала?:)

Ну вобще с локальной scala user group все (и компании и программисты) так или иначе пересекаются. У нас — группа google scala-ua или сообщество в FB: www.facebook.com/...56373621041781 (к новому году руки дойдут сайт сделать)

К сожалению на этой неделе под скалу подложили слишком большую бомбу — и для меня она плавна выбыла из потенциально интересных технологий. я о пресловутом письме Coda Hale к Donald Fischer и Martin Odersky

По моему это серьезный если не фатальный удар по репутации скалы как продакшен решения.

Думаю что никак не повлиет. Есть позитивный опыт твиттера, линкедина, foursquare, клоут и еще с десятка взрослых компаний. Наоборот было-бы странно если бы были только успехи и не было бы проблем

Движения индустрии в сторону scala определяется тем, что большинство хороших java-программистов, попробовав scala к java стараются не возвращаться и для них эта ситуация скорее удар по репутации yammix чем typesef.

ИМХО, самый главный риск разработки проекта на Scala — это то, что соседняя контора переманит у тебя обоих единственных в Украине программистов на Scala :)

Да ладно — вон вчера человек 20 пришло, это без особых анонсов и только в Киеве. Нет, пишут и довольно интересные вещи. Тут скорее наоборот — из jav-истов как раз никого нормального не найдешь, потому что все продвинутые переключились на что-то более современное.

Тут скорее наоборот — из jav-истов как раз никого нормального не найдешь, потому что все продвинутые переключились на что-то более современное.
Толсто. Когда за скалу начнут платить больше, тогда и получите грамотных скалистов — бывших явишников.
<troll-mode>
Тут вобще неприменима биржевая оценки, так как на бирже торгуется только стандартный товар, а скалисты [пока ?] - товар штучный ;)))

</troll-mode>

Может скала банально не так хороша, как некоторые думают?

А в чем смысл перехода на scala? Тут java спецов найти трудно, а с опытом на scala так вообще не реально. Вы изначально заложили огромные риски в проект в случае его быстрого роста. Не понятно.

А в чем смысл перехода на scala?

Кучи ... точнее горы ... не все-таки кучи фана! Можно наделатьтакой код шо ни на каком питоне, руби или джаваскрипте не повторишь.

Фан фаном, а работа работой. Не думаю, что заказчикам понравится ситуация, когда после Вас никто не сможет разобраться в коде =)

...да и вообще, через пару дней сам свой код прочитать не сможешь :)
надо всё-таки отделять фан от работы.

Я какбэ об этам же (поэтому и использовал слово «кучи»).

Кучи вполне умудряются и на python откладывать, я по огромному опыту ревью точно знаю. А на языках куда стараются внедрить побольше сахара, понятно что кучи будут еще выше.

на JS можно делать весьма извращенно, насмотрелся последнее время. Особенно если есть усидчивые но не очень просветленные програмисты.

Кстати в этом плане скала всеже «рулит», ибо статик тайпинг. Можно гдето кудато отследить, что происходит (если саму скалу хорошо знать).

Переходят из-за:
1) внятной многопоточности на Actors и как следствие масштабируемости
2) компактность кода, бывает до 10 кратного сокращения.(в сравнении с java)

3) полный фарш java библиотек

Я еще котирую сам функциональный подход. Для Twitter и Foursquare в свое время был важной вехой в масштабировании. И это при том, что у этих стартапов колосальный рост уже несколько лет.

Мельком прочитал про многопоточность в скала. Да, на первый взгляд — гораздо проще. 2-й и 3-й пункты не аргументы в пользу перехода на скала. Надо будет поковырять, может пойму преимущества.

Ну, так тут главное что для вас важно — JVM или сам язык java. Я в свое время долго мучался между scala и clojure оба обеспечивают описанные вверху вещи. Я выбрал clojure так как знаю lisp. Scala интересуюсь для поддержания тонуса. Для меня лично возможность написать в 1 строку, то что на джава пишеться в 10 была ключевой. В день можно писать на порядок больше эффективного кода за меньший промежуток времени.

Scala, кстати, получила грант на 3млн евро от ЕС, так что на месте язык стоять не будет.

Для меня лично возможность написать в 1 строку, то что на джава пишеться в 10 была ключевой.

А можно какой нибудь пример?

Я не нашел там примеров соотношения 1:10. Ну и код вида: (n: Int) => (2 to n) |> (r => r.foldLeft(r.toSet)((ps, x) => if (ps(x)) ps — (x * x to n by x) else ps)) считается достаточно читабельным что бы его приводить в пример?

Для 1:10, надо искать, извиняюсь. Просто ссылка была под рукой, решил привезти в пример.

Последний код, конечно, на код-ревью я бы не пропустил.

Еще там много вариаций вокруг closures, которые просто синтакс. сахар над анонимными классами, но и с ними можно вполне жить, я например обычно пишу такой код:

ret = Collections2.filter(in, EXCLUDER_GREATER_60);
Predicate<integer> EXCLUDER_GREATER_60 = new Predicate<integer>() {
public boolean apply(Integer i) {
return i <= 60;
}
};

Так вот, все кроме строк 1 и 4 мне сгенерит ИДЕ, т.е. я пишу только две строки руками. Можно жить вроде.

Это вместо

in.filter( _ <= 60 )

Как в том анекдоте — «можно, только зачем ?» ;)

Как в том анекдоте — «можно только зачем ?» ;)

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

Без closures жить можно, мне например не так часто в коде нужно что-то такое писать. Меня в джаве больше напрягает куча другого boilderplate-a.

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

Впрочем груви не скала, в скале с этим вроде все нормально и совать клосюры где попало нету желания (только «чистые» функции )).

Немного поехала верстка, но смысл понятен.

Жить можно на Java преспокойно. И код авто-генерить и прочее. Там выше люди писали про having fun. Сахару дали — надо брать, я считаю, пока дают :)

Scala, кстати, получила грант на 3млн евро от ЕС, так что на месте язык стоять не будет.

Точно? Насколько я слышал то команда частью которой является команда разрабатывающая скалу получила гранд на исследования распределенных вычислений. www.scala-lang.org/node/8579

Там вобще было не одно вливание, при этом как в универ (как эти 2.3 млн ) так и в typesafe (как коммерческую организацию) . Если про 3 млн то это очевидно греулоковские инвестиции: greylockvc.com/...d-modern-tools

Холивора ради.
1) Реализации акторов, стм, и всякого прочего вполне под жава есть.
2) за компактность платим плохим пониманием того что внутри происходит. В результате если упираемся в производительность то имеем огромнешую кучу проблем. Письмо Хала какраз это демонстрирует.
3)Жава библиотекам в скале местами мерзко, имхо, пользоваться :-) Но самое главное что жава библиотеки в жаве таки доступны.

за компактность платим плохим пониманием того что внутри происходит. В результате если упираемся в производительность то имеем огромнешую кучу проблем. Письмо Хала какраз это демонстрирует.

— ну обычно, если пишут высокопроизводительный сервис то обычно сначала проектируют, при этом прототипируя архитектуору и делая какие-то эксперименты, а потом вставляют мониторинг производительности в общую структуру. Судя по письму Хала, непонятно сделали ли они 1-е , но понимать что происходит — они понимали. Мне показалось, что в рамках той архитектуры которую они выбрали, у них последовательная скала использовалась как замена последовательной джавы, поэтому они для максимальной производительности избавлялись от for и клозур и использвоали java коллекции: то есть фактически писали критические точки в java стиле. Ну так тогда действительно, эти места проще на java писать. Другой вопрос как так оказалось что у них — почти все — это тонкое место *последовательного* выполнения. Такого в жизни практически не бывает, а если бывает то лечение это обычно вынос части функциональности в асинхронные процессы, выполняющиеся параллельно, а не попытка микрооптимизаций. Ну тут, правда, сказать что у них было нельзя, потому такие догадки могут быть и пальцем в небо.

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

Вы противопоставляете грамотный подход не грамотному, но это никак не связано со скалой. (Если я вас правильно понял).

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

На мой взгляд, скала более интересна как раз опытному синьору для реализации каких-то изолированных вещей (например, какой-то сервис куда никто не полезет еще несколько лет)

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

хорошие люди подбираются медленно и это не зависит от языка.

Согласен. Но количество так же имеет значение:
1) Очень много людей (например, ПХП) — сложно найти адекватных
2) Оптимальное количество (в некоторой мере джава)
3) Очень мало людей (например лисп) — большие риски: если один из 2 лисперов в вашей конторе уйдет. Скала — сложный язык, людей которые на нем умеют писать мало (именно умеют, а не просто пробовали). Снова же за счет сложности, адекватного человека подготовить качественного джависта проще чем скалиста.

Когда-то была такая шутка: А что джуниор ЦПП программисты могут существовать хоть в теории?

это в какой-то мере справедливо. Но в конце концов в С++ выработалось подмножество языка на котором могут писать все (по иронии судьбы, лучше всего описанное в С++ google coding style ;)) а вещи типа сложный темплейтов с частичной специализации используются «программистами второго порядка» [ при разработке библиотек ].

а само слово «грамотный» появилось в ответе из=за указание на риски. То есть это скорее недостаток scala — что там для взаимозаменяемости программистов подход должен быть грамотным, а java к этому менее требовательна

Наоборот, при грамотной разработке в java проекте, разработанной небольшой командой и постепенным вводом в тему новых людей, меньше технических рисков, чем если взять орду scala синьйоров и посадить их быстро копать что=то нетривиальное

Что-то поменялось? При чем тут скала?

очевидно scala и java поменялись местами ;)

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

К тому времени транзакция уже завершиться, соответственно попытка чтения вызовет исключение

Не совсем понятно, кто завершает транзакцию? или она отваливается по таймауту?

Транзакция завершается в конце блока transaction (или самого внешнего вхождения inTransaction)

В целом, мне ситуация со scala очень напоминает С++ в 90-ых: сравнительно большой и сложный язык, кривой во многих местах, но дающий настолько мощный сдвиг мышления и повышения эффективности разработки, что инвестиции в обучение и обход потенциальных проблем заведомо окупаются с лихвой, так что сегодня разработка на «чистом C» стала уже маргинальным явлением.

Как так? Функциональные языки более 50 лет существуют Lisp, Scheme же, scala оттуда все плюшки тырит безбожно.

так что сегодня разработка на «чистом C» стала уже маргинальным явлением.

Я поддержу назревающий холивар, С++ костыли, это факт, грамотное использование С, решает 80% задач.Често скажу, С++ «не асилил» еще в универе, зато С просто на ура.С++ никакого сдвига мышление, скорее выковыривание мозгов серебряной ложкой. Lisp, Clojure вот там сдвиг...

Скала скорей «тырит» фишки у хаскеля и ерланга.
С си++ можно сравнить в том плане, что со скалой можно сходу работать пользуясь знакомыми концепциями, постепенно «расширяя сознание» до функционального программирования. С с++ похуду было тоже самое.

А после одной только джавы сразу «ментально осилить» кложур — ой как сложно :-)

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

Но мне кажется, что основная проблема Scala — да и не проблема это, в общем — относительная молодость языка и, как следствие, — отсутствие того, что принято называть effective practices. В сети еще очень и очень мало материалов о том, как именно следует использовать языковые возможности, какого стиля придерживаться, какие компоненты предпочтительнее использовать и в каких сценариях. Информация об этом все-таки есть, но она разрозненная. Что нужно Scala сообществу, так это чтобы кто-то собрал все и скомпоновал в презентацию-бомбу, которая бы разошлась огромным тиражом и стала бы обязательной к просмотру. Ее бы рассылали по корпоративной почте, ее бы копировали и показывали на локальных IT-конференциях и даже перевели бы на японский. Что-то а-ля презентаций Рича Хикки «Are we there yet» и «Simple made easy». Это может быть и цикл статей, и даже книга. Но что-то такое нужно.

Если у вас есть опыт, если у вас есть какой-то багаж практик, могли бы заняться.

Книг завались и даже на японском, честное-причестное. Просто на scala можно кодить только из Emacs, а сейчас все привыкли к IDE и плюются непомерно при отсутсвии кошерных инструментов разработки.

Мы делали опрос — кто чем пользуется. Больше всего eclipse, потом emacs и idea. (И говорят что у idea лучше всего вышло но она дорогая, а среда eclipse уже юзабельна)

IDEA CE бесплатная, плагин для Scala — тоже. Не вижу проблемы.

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

nightly builds scala плагина для IDEA 11 очень даже. Дебагер понимает скаловские заморочки и умеет evaluate expression делать. Но все вкусности появились под IDEA 11, которая сейчас RC. Вот блог плагина — blog.jetbrains.com/scala

Я по emacs,одна среда для всего, мне эти гружоные IDE уже в печенках сидят =) и это все недавно появилось..

Меня команда пыталась подсадить на Emacs/Vim. Я старался, честно. Но после долгой работы в Eclipse IDE это было мучение. А потом выяснилось, что у компании есть лицензия для IDEA, и вопрос вообще отпал сам собой. У IDEA (даже 10), вполне нормальный Scala-плагин. Гораздо лучше того, что в Eclipse IDE. Среда разработки — это дело привычки/вкуса. Иногда это guideline на проекте, конечно, но всему можно научиться, если нужно.

Да есть процесс такой, на scala-days и scala- кстати Joshua D. Suereth в таком роде неплохую презентацию делал (и у него летом книга выйдет) www.manning.com/suereth . На конференциях о best practices обычно очень много говорят, так что, думаю набор критической массы эффективных соглашений — дело времени.

Effective practices — есть или нет, именно для меня это не важно, в виду того что с помощью Scala и Lift фреймворка у меня за 1 неделю делается то, что в связке Java+Wicket+Hibernate делалось 4-5 недель. При этом результирующий объём и сложность кода в несколько раз меньше (да-да, и сложность тоже). Если не сильно извращаться с функциональными конструкциями scala, то код легко читается mid джава девелопером после 15-минутного прояснения базовых конструкций скалы и фреймворка. Learning curve, небольшая популярность, сложности с поиском людей и другие проблемы, которые могут ассоциироваться со скалой — а как вам поиск людей для кодинга на кастомном ассемблере для кастомного железа? А на XML-подобном языке для embedded UI? А поиск джавистов для кодинга с помощью JSP + EJB 2.0 ? :-)) Всё это проходилось в плане хаиринга уже несколько раз. И на удивление люди находятся. Так что не думаю что это причина делать реджект для scala во время выбора технологий.

в виду того что с помощью Scala и Lift фреймворка у меня за 1 неделю делается то, что в связке Java+Wicket+Hibernate делалось 4-5 недель.
Сколько мажорных релизов было? Как обновилась команда? Сколько человек работают над проектом? Как производительность?

вообще я сейчас озадачен выбором технологий для мелкого домашнего проекта. Интерисует в первую очередь стабильность среды и инструментария ( привет node.js ты класный но утомляеш падучими обновлениями что ппц) и ± разумное потребление ресурсов ( тк amazon скорее всего или что то аналогичное) . Интересно было бы услышать плюсы и минусы по Lift на ваш всгляд и как там с поддержкой mongodb (если использовали такую связку)

TypeSafe нынче play framework продвигает, так что возможно стоит ориентироваться на него а не на лифт.

да, смотрел на него но совсем немного... Испугал свой сервер если чесно. Но выглядит заманчиво

А вам не наплевать, что там за сервер? Все равно же все за Nginx спрячете.

play framework приложение можно упаковать в war и задеплоить на любой сервлет контейнер.

спасибо за информацию, это хорошо.

хм. а как насчет Clojure + Compojure? имно, куда проще и легковеснее (по сравнению со связкой Scala + Lift/Play), и деплоится на Heroku с полпинка.

Lift я не очень люблю, предпочитаю scalatra или тот-же play. Хотя он тоже работает (хуже масштабируется, так как не stateless, но в 90% случаях это неважно) Поддержка mongodb там есть. Вобще как введение в набор фреймворков: www.quora.com/...s-disadvantages

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

Сейчас можно выбрать Hibernate, Spring, GWT, Maven — и быть уверенным, что в течение ближайших пяти лет с трудоустройством у вас проблем не будет: проектов на этих технологиях вагон и маленькая тележка. Вам никто не мешает перепрыгивать из компании в компанию, добиваясь приличного роста зарплаты, и даже добиться положения тимлида и менеджера. При этом ничего учить особо не надо — потратил с годик на заре карьеры и все: обучение закончилось. И к сожалению, очень и очень многие идут по этому пути.

И вот ты собеседуешь такого специалиста и говоришь ему, что у нас проект нетипичный, что, например, основная логика на клиенте, а с сервером мы общаемся через JAX-RS; или, например, что с базой данных мы общаемся через Spring JDBC templates; или что у нас Spring не используется; или что часть системы на Python написана, или еще что-то. А кандидат смотрит на тебя пустыми глазами, говорит, что это не его профиль и уходит. И это при том, что говоришь ему: если что-то не знаешь, с чем-то не работал, то не страшно: мы всему научим.

А насчет примера, который вы предложили, я ничего сказать не могу: ни с Lift, ни c Wicket не работал. Мне как-то всегда больше request-oriented фреймворки больше нравятся.

Подписаться на комментарии