скажу больше, проект по переезду мы стартанули одновременно в 3 командах и как раз хотели единым путём пойти сперва. и устраивали встречу с Владимиром, перенять опыт. но у почты переезд занял 3+ года, но и масштабы другие. в итоге вскоре каждая команда пошла своим путем :) весь вопрос как раз в стартовых условиях и ограничениях. сколько данных? как лежат? можно по частям? возможен даунтайм? сколько человекорук? есть сроки?... и у всех команд все отличалось. из универсальных шагов наверно только выкинуть все лишнее, чтоб не мешало, да обложиться тестами
немножко ошибок всплыло после окончательного переключения (роутинг ENABLED), но как я написал, в течение пары часов хотфиксами все поправилось. ошибок было очень мало, тк они почти все были про запись (где-то тестов не хватило), а не про чтение, ошибки чтения безопасно ловились остальными режимами роутинга. в качестве пруфов хотел прицепить скрин из чата в день переезда, но чатик за давностью умер :)
мы открывали краник с роутингом на несколько минут - набирали ошибок / стату по запросам - краник закрывали :) ошибки до юзеров не долетали, тк все они только в логах оседали (роутинг NOOP_REPEAT). а на тайминги смотрели на графики, если вдруг улетало сильно вверх, сразу краник закрывали и шли лечить performance
занимались, но pg гораздо больше developer-friendly. в оракле была и куча хинтов, и гвоздями прибитые планы для критичных запросов, и регулярная помощь dba (которых на всех не хватало). а на pg еще сильно помогли инструменты managed pg из облака - заходили, смотрели стату по запросам, и резали топ проблем. так победили :)
Правильно пишете. Та самая тонна возможностей порождает кучу неоднозначностей. Люди любят бросаться в крайности и использовать найденные мегафичи к месту и не к месту, а в Scala их навалом и договориться оч сложно. Можно провести мысленный эксперимент: взять какую-нибудь Java-команду, и если каждый по отдельности начнет интересоваться и пробовать Scala, то со временем всем настолько понравится, что захотят проект частично/полностью смигрировать. Но полученный в изоляции опыт и впечатления у всех будут разными, вот и получится каша. Наверное единственный вариант этого избежать — учиться всем одновременно и централизованно, тогда и все соглашения будут всем понятны.
Что касается Closure, то мне кажется, народ начинает интересоваться им (и прочими ФЯП) по причине «о, да тут после сплошной Java-императивности еще и функциональщина есть, выглядит интересно, надо еще покопать в ту сторону».
Если у них все получится, то в первую очередь, думаю, обрадуются владельцы смартфонов, планшетов и ноутов, раз уж везде будет халявный wi-fi. А вот обрадуются ли операторы сотовой связи, ооочень сомневаюсь. Спутники начнут отстреливать…
Если устраивает Gradle, то зачем менять? Можно подождать пока SBT заматереет, либо пока деваться будет некуда. У SBT версия-то нынче всего-лишь 0.13.1, значит сами авторы считают ее далекой до завершения.
Согласен, не была, но бонусы можно было получать уже тогда. Хотя бы как «Java с val и без точек с запятой».
Про Play не могу сказать, я сейчас с ним только знакомлюсь.
Про разность стиля это да, доходит до крайностей, чему в том числе способствует возможность писать методы почти с произвольным названием из кучи символов. Но мы так не делаем, читабельность is the must.
PS: Я имел ввиду что очень не хватало неизменяемой коллекции, у которой есть size.
Просто Scala как молодой язык (по сравнению с Java) развивается быстрее. Если вдруг Scala завладеет массами в таких же масштабах, как Java, думаю она тоже затормозит по добавлению фич всяких.
Полагаю, речь не о Maven-based проекте? Если так, то в IDEA меню File — Project Structure — Libraries, там добавить нужный вам org.scala-lang:scala-lang-compiler. Далее идем в список фасетов и в каждом Scala-фасете меняем Compiler library на только что добавленную. С Maven / SBT / Gradle вопрос снимается автоматом, возьмется указанный в соответствующем конфиге. В IDEA 12 и ранее, когда был FSC, можно вроде было только ему засетить эту либу и в фасетах выбрать use project FSC (вроде так было, не помню, у нас уже IDEA 13).
Мы начали этот процесс перехода 2 с лишним года назад, так что эти плюшки мы получили когда еще Java 7 не появилась. Насчет перехода на другой язык я в самом начале поста упомянул — переписывать всю codebase на не-JVM язык мы не собирались, это были бы нереальные временные затраты.
Вообще говоря, смотря как писать. Если написать один и тот же код на Java и Scala, то разницы не будет, байт-код генерится один и тот же практически. Если же какой-нибудь алгоритм реализовать совершенно разными путями, можно и получить совершенно разные результаты (например см DZone). Scala может генерировать кучу объектов, например анонимных функций или промежуточных коллекций. Скажем в выражении вида someCollection.filter(x => …).map(x =>…) будет 2 анонимных класса для каждого (x => …) плюс временная коллекция между filter и map (более развернутый ответ например на StackOverflow)
Как я уже упомянул, есть плагины для IntelliJ IDEA и Eclipse, оба активно развиваются. О других не слышал. Дополнение и отладка в обеих поддерживаются на хорошем уровне. Какую IDE из них выбрать — дело вкуса мне кажется.
мы сильной разницы не заметили. классы обычно не очень большие, поэтому инкрементальная сборка со своей задачей справляется хорошо. у упомянутого Maven-плагина для этих целей есть goal scala:cc, у IDEA compile-server, у SBT режим continuous compilation.
скажу больше, проект по переезду мы стартанули одновременно в 3 командах и как раз хотели единым путём пойти сперва. и устраивали встречу с Владимиром, перенять опыт. но у почты переезд занял 3+ года, но и масштабы другие. в итоге вскоре каждая команда пошла своим путем :) весь вопрос как раз в стартовых условиях и ограничениях. сколько данных? как лежат? можно по частям? возможен даунтайм? сколько человекорук? есть сроки?... и у всех команд все отличалось. из универсальных шагов наверно только выкинуть все лишнее, чтоб не мешало, да обложиться тестами
немножко ошибок всплыло после окончательного переключения (роутинг
ENABLED), но как я написал, в течение пары часов хотфиксами все поправилось. ошибок было очень мало, тк они почти все были про запись (где-то тестов не хватило), а не про чтение, ошибки чтения безопасно ловились остальными режимами роутинга. в качестве пруфов хотел прицепить скрин из чата в день переезда, но чатик за давностью умер :)мы открывали краник с роутингом на несколько минут - набирали ошибок / стату по запросам - краник закрывали :) ошибки до юзеров не долетали, тк все они только в логах оседали (роутинг
NOOP_REPEAT). а на тайминги смотрели на графики, если вдруг улетало сильно вверх, сразу краник закрывали и шли лечить performanceзанимались, но pg гораздо больше developer-friendly. в оракле была и куча хинтов, и гвоздями прибитые планы для критичных запросов, и регулярная помощь dba (которых на всех не хватало). а на pg еще сильно помогли инструменты managed pg из облака - заходили, смотрели стату по запросам, и резали топ проблем. так победили :)
Что касается Closure, то мне кажется, народ начинает интересоваться им (и прочими ФЯП) по причине «о, да тут после сплошной Java-императивности еще и функциональщина есть, выглядит интересно, надо еще покопать в ту сторону».
Про Play не могу сказать, я сейчас с ним только знакомлюсь.
Про разность стиля это да, доходит до крайностей, чему в том числе способствует возможность писать методы почти с произвольным названием из кучи символов. Но мы так не делаем, читабельность is the must.
PS: Я имел ввиду что очень не хватало неизменяемой коллекции, у которой есть size.
someCollection.filter(x => …).map(x =>…)будет 2 анонимных класса для каждого(x => …)плюс временная коллекция междуfilterиmap(более развернутый ответ например на StackOverflow)scala:cc, у IDEA compile-server, у SBT режим continuous compilation.