ARM от Scaleway не советую, так как производительность вообще никакая. Кроме того, есть старый софт который вы не сможете поднять/скомпилировать под ARM. У меня есть несколько старых php проектов, которые работают на версии 5.2, так вот в режиме php-fpm вы их не поднимете на ARM, банально не соберется на этой платформе. (я в конце-концов заморочился, и таки завел его, но страдать таким — только если есть время и желание)
ARM вариант потерял всякий экономический смысл когда появились x86 виртуалки по такой же цене, и с тем же кол-вом RAM, куда я успешно и смигрировал впоследствии.
Судя по тому что я читал на местных форумах самоподдержки, люди в основном его используют для автосборок/тестирования под спец-железо.
Кстати, верно подмечено — у нас сейчас 3 приложения, суммарно время компиляции составляет в районе получаса. При этом мы поддерживаем только Gecko/IE8/Webkit (то есть еще и не все пермутации компилируем)
Ну а на машинах рядовых девелоперов получается существенное ускорение если пересесть на SSD, докинуть памяти хотя бы до 8гб, и сидеть на чем-то вроде core i5
Согласитесь, гораздо меньше людей размещают в Гугле рекламу, чем редактируют документы.
я все-таки позволю себе не согласиться =)
По-поводу вашего опыта использования — очень интересно было бы еще в деталях почитать, особенно про связку Knockout + Underscore, возможно у вас где-то завалялись записи в личном блоге. У меня такого опыта к сожалению не было, и кстати, выбор в пользу GWT делался почти 2.5 года тому назад, когда про такие либы ничего не было слышно. Тогда мы рассматривали вещи типа jQuery UI, YUI Library, SproutCore, Javascript MVC, Cappuccino.
Ну и насчет количества людей занятых в проекте, могу смело сказать что java как база для GWT себя полностью оправдала. У меня теперь не будет болеть голова даже если количество народу увеличить вдвое.
В чем прокол у явасрипта как у набора тулзов и как языка — так это в сложности поддержания дисциплины. А вот как раз java для этого подходит более чем, так как тут тебе весь набор средств — начиная от строгой типизации в самом языке, заканчивая тоннами готовых утилит для контроля за качеством кода.
Спорить хорошо это или плохо — предмет другого разговора, до старта проекта на GWT у меня был за плечами опыт PHP / Javascript(prototype, jquery), Delphi, Pascal(x86) и всякое еще разное по мелочам. Но вот на чем мне уж точно не хотелось писать после PHP (CakePHP) — так это на Яве, страшилки про мегабайты XML файлов конфигураций, сотни иерархий классов с интерфейсами — все это меня откровенно пугало.
Я сторонник концепции convention over configuration, которая кстати сказать, отлично работает в маленьких командах и на динамических языках типа Python/Ruby/JS. То есть при прочих равных, проще договориться между собой и использовать гибкий динамический язык, чем клепать тонны конфигураций и делать средства для контроля кода — но на сложных проектах с кучей людей, увы, другие законы — договориться становится просто физически нереально.
Собственно, перелопатив тонны разных решений, ничего особенно и не оставалось кроме GWT для решения нашей задачи. Какие бы у меня личные предпочтения не были на тему Явы, нужно было решать поставленную задачу подходящим инструментом.
Касательно тест-задания про редактируемый grid — точно могу сказать, что скорость создания своих компонентов(виджетов) в GWT таки будет казаться черепашьей по сравнению с обычным яваскриптом. Но как только этот компонент написан — тут уж re-use идет капитальный. Мы по этой причине вначале очень сильно тормозили, так как нужно было много чего сделать с нуля (из стандартных GWT виджетов мы использовали только несколько, все остальное пришлось делать самим)
В общем, резюмировать могу вот этой замечательной картинкой :)
Да, по ходу дела, наши стейкхолдеры иногда задалбывают неудобными вопросами — зачем нам GWT, которое не очень-то популярно(стоимость программиста сильно выше), разработку точно уж agile не назовешь (dev-mode тормозит, java overhead и все сопутствующие) ну и т.п. в том же духе. В какой-то момент, я решил более ясно изложить нашу позицию и родил опус Why GWT? — там более развернуто расписано почему и когда нужно выбирать GWT.
Аргументы по существу к вашим замечаниям
a) На GWT написан Adwords — основной продукт на котором держится весь бизнес Google, преувеличивать используя историю с закрытием Wave явно не стоит
b) Дебажить в яваскрипте всегда было адски непросто, если вы тут упоминаете IE9 Dev Tools как средство для дебага в IE — это гкхм… мягко говоря, вы им мало пользовались на огромных проектах. Firebug, Chrome dev tools — тут претензий нет, IE dev tools — откровенно унылое говно, может на hello world оно и работает адекватно, но явно не на чем-то большом.
Ок, насчет либ и модульности — все вроде как правильно, решать задачи можно и яваскриптом, очень классно что за последние пару лет появилось на эту тему масса отличных библиотек.
Но вот незадача, представьте себе проект жирного клиента в браузере с командой в 10+ человек, Enterprise уровня, что-то вроде Adwords интерфейса, работающего с разными кастомными API и имеющий очень нехилое Desktop-alike GUI, и нетривиальной бизнес логикой.
И вот перед вами задача, как у ответственного за выбор технологии — на чем это все писать? Да, при этом вы понимаете, что вам и самому-то далеко до уровня хотя бы того же Крокфорда, не то что будущим 10+ членам вашей команды.
По-ходу дела, вы также перелопатили кучу JS библиотек, которые как бы вроде и решают задачу, но каждая — какую-то свою отдельную, и ведь мечтается взять сразу что-то готовое и цельное, чтобы и архитектура правильная (MVP), и коммунити было, и документация вменяемая, и т.п. и т.д.
Вот если взглянуть на GWT немного со сдвигом в бизнес, а не в быстроту манипуляции домом и прочие технические нюансы — какое бы вы решение приняли?
ARM вариант потерял всякий экономический смысл когда появились x86 виртуалки по такой же цене, и с тем же кол-вом RAM, куда я успешно и смигрировал впоследствии.
Судя по тому что я читал на местных форумах самоподдержки, люди в основном его используют для автосборок/тестирования под спец-железо.
Для регулярных билдов решаем супер-компьютером High-Memory Quadruple Extra Large Instance, удается сократить время до 20минут.
Ну а на машинах рядовых девелоперов получается существенное ускорение если пересесть на SSD, докинуть памяти хотя бы до 8гб, и сидеть на чем-то вроде core i5
Согласитесь, гораздо меньше людей размещают в Гугле рекламу, чем редактируют документы.
я все-таки позволю себе не согласиться =)
По-поводу вашего опыта использования — очень интересно было бы еще в деталях почитать, особенно про связку Knockout + Underscore, возможно у вас где-то завалялись записи в личном блоге. У меня такого опыта к сожалению не было, и кстати, выбор в пользу GWT делался почти 2.5 года тому назад, когда про такие либы ничего не было слышно. Тогда мы рассматривали вещи типа jQuery UI, YUI Library, SproutCore, Javascript MVC, Cappuccino.
Ну и насчет количества людей занятых в проекте, могу смело сказать что java как база для GWT себя полностью оправдала. У меня теперь не будет болеть голова даже если количество народу увеличить вдвое.
В чем прокол у явасрипта как у набора тулзов и как языка — так это в сложности поддержания дисциплины. А вот как раз java для этого подходит более чем, так как тут тебе весь набор средств — начиная от строгой типизации в самом языке, заканчивая тоннами готовых утилит для контроля за качеством кода.
Спорить хорошо это или плохо — предмет другого разговора, до старта проекта на GWT у меня был за плечами опыт PHP / Javascript(prototype, jquery), Delphi, Pascal(x86) и всякое еще разное по мелочам. Но вот на чем мне уж точно не хотелось писать после PHP (CakePHP) — так это на Яве, страшилки про мегабайты XML файлов конфигураций, сотни иерархий классов с интерфейсами — все это меня откровенно пугало.
Я сторонник концепции convention over configuration, которая кстати сказать, отлично работает в маленьких командах и на динамических языках типа Python/Ruby/JS. То есть при прочих равных, проще договориться между собой и использовать гибкий динамический язык, чем клепать тонны конфигураций и делать средства для контроля кода — но на сложных проектах с кучей людей, увы, другие законы — договориться становится просто физически нереально.
Собственно, перелопатив тонны разных решений, ничего особенно и не оставалось кроме GWT для решения нашей задачи. Какие бы у меня личные предпочтения не были на тему Явы, нужно было решать поставленную задачу подходящим инструментом.
Касательно тест-задания про редактируемый grid — точно могу сказать, что скорость создания своих компонентов(виджетов) в GWT таки будет казаться черепашьей по сравнению с обычным яваскриптом. Но как только этот компонент написан — тут уж re-use идет капитальный. Мы по этой причине вначале очень сильно тормозили, так как нужно было много чего сделать с нуля (из стандартных GWT виджетов мы использовали только несколько, все остальное пришлось делать самим)
В общем, резюмировать могу вот этой замечательной картинкой :)
Да, по ходу дела, наши стейкхолдеры иногда задалбывают неудобными вопросами — зачем нам GWT, которое не очень-то популярно(стоимость программиста сильно выше), разработку точно уж agile не назовешь (dev-mode тормозит, java overhead и все сопутствующие) ну и т.п. в том же духе. В какой-то момент, я решил более ясно изложить нашу позицию и родил опус Why GWT? — там более развернуто расписано почему и когда нужно выбирать GWT.
a) На GWT написан Adwords — основной продукт на котором держится весь бизнес Google, преувеличивать используя историю с закрытием Wave явно не стоит
b) Дебажить в яваскрипте всегда было адски непросто, если вы тут упоминаете IE9 Dev Tools как средство для дебага в IE — это гкхм… мягко говоря, вы им мало пользовались на огромных проектах. Firebug, Chrome dev tools — тут претензий нет, IE dev tools — откровенно унылое говно, может на hello world оно и работает адекватно, но явно не на чем-то большом.
Ок, насчет либ и модульности — все вроде как правильно, решать задачи можно и яваскриптом, очень классно что за последние пару лет появилось на эту тему масса отличных библиотек.
Но вот незадача, представьте себе проект жирного клиента в браузере с командой в 10+ человек, Enterprise уровня, что-то вроде Adwords интерфейса, работающего с разными кастомными API и имеющий очень нехилое Desktop-alike GUI, и нетривиальной бизнес логикой.
И вот перед вами задача, как у ответственного за выбор технологии — на чем это все писать? Да, при этом вы понимаете, что вам и самому-то далеко до уровня хотя бы того же Крокфорда, не то что будущим 10+ членам вашей команды.
По-ходу дела, вы также перелопатили кучу JS библиотек, которые как бы вроде и решают задачу, но каждая — какую-то свою отдельную, и ведь мечтается взять сразу что-то готовое и цельное, чтобы и архитектура правильная (MVP), и коммунити было, и документация вменяемая, и т.п. и т.д.
Вот если взглянуть на GWT немного со сдвигом в бизнес, а не в быстроту манипуляции домом и прочие технические нюансы — какое бы вы решение приняли?