Ну я надеялся на то, что человек не случайный в веб и руби разработке сможет без труда подучить тот или иной гем. Это же не квантовая физика.
Плюс данный генератор я писал скорее для себя, потому что часто бывает необходимо за короткое время накидать API, поэтому основывался на тех гемах, которые использую.
Делайте ради бога, я же вас не принуждаю.
В нем нет ничего такого, что вы не сможете сделать как с помощью «обычных контроллеров» (я так понимаю, вы про Rails), так и с помощью любого другого веб-фреймворка на любом другом языке.
Это просто фреймворк для тех, кому не нужны рельсы для разработки API.
Вы считаете, что это плохо, когда существует несколько способов решить одну и ту же задачу?
Есть два типа людей — одни покупают готовый, отлично выглядящий дом, живут в нем полгода, а когда из подвала начинает вонять дерьмом, берут фонарь и спускаются посмотреть, что же там такое. Оказывается канализацию прорвало, надо чинить.
Другие покупают стройматериалы, делают проект, льют фундамент и.т.д.
Не имею ничего против ни первых, ни вторых. Просто люди по-разному получают фан.
Да, gulp-watch использую очень активно, но ни разу не встречался с вышеупомянутыми ошибками. Посмотрел issues — может быть это потому, что у меня OS X.
Обработку ошибок без подвисания стрима можно сделать через gulp-plumber. Его офигенный плюс, что он работает на уровне pipe, следовательно нет необходимости в каждом плагине делать .on
Насчет замены sass на stylus ради ускорения компиляции — gulp-sass использует для компиляции node-реализацию процессора, libsass. Отрабатывает практически моментально даже на здоровенных файлах.
К нему можно добавить compass с помощью bower-пакета compass-mixins, специально созданного для замены ruby-compass в libsass.
Жаль, что не была затронута тема инкрементальных билдов.
Бесплатно доступна Starter Edition. Обычная стоит $30, Full edition $70 book.discovermeteor.com/chapter/github — отсюда начинаются платные главы, т.е. бесплатных там четыре главы включая введение.
Вот я все хочу попробовать, но никак не могу побороть ощущение, что это такая «вещь в себе»
Может быть вы меня не совсем правильно поняли — задваиваются роуты именно в случае релоада классов, унаследованных от Grape. Это не ошибка Padrino::Reloader, так Grape устроен.
Не совсем понял, что вы имеете в виду под реюзом кода. Случай, когда Grape подключается к Rails и использует его модели? Если да, то это без проблем.
Я в первую очередь хотел показать, как можно жить без Rails и не отказывать себе ни в чем, хотя бы а рамках написания API.
Зависит от того, насколько вы терпеливы. Shotgun на каждый запрос будет заново загружать файлы проекта — если их у вас не 2 а 20, то это примерно 3 секунды.
Из-за специфики кода Grape его нелья перезагружать просто выгрузкой объявленных констант и повторным require изменившегося файла.
Когда я начал свои изыскания в этом вопросе, я первым делом прицепил Grape к Padrino, у которого достаточно неплохой релоадер. Это сработает в определенных пределах — простое приложение типа этого HelloWorld будет перезагружаться, но начнут задваиваться роуты — это можно увидеть подключив grape-swagger. Потом я попытался пропатчить Grape::API, чтобы заставить его нормально работать с Padrino::Reloader — то, что получилось в итоге, по времени релоада мало отличалось от shotgun.
Поэтому я написал отдельный гем, который делает это с учетом специфики Grape — он делает кучу манки-патча Grape::API класса для dev-окружения.
Гем пускай развивается, это правильно. Но какой смысл релизить гем, который даже не бета?
Вы же знаете, что необязательно релизить гем, чтобы его в Gemfile прицепить?
Вместо Oj я бы использовал сразу MultiJson, так будет поддержка JRuby.
Плюс данный генератор я писал скорее для себя, потому что часто бывает необходимо за короткое время накидать API, поэтому основывался на тех гемах, которые использую.
В нем нет ничего такого, что вы не сможете сделать как с помощью «обычных контроллеров» (я так понимаю, вы про Rails), так и с помощью любого другого веб-фреймворка на любом другом языке.
Это просто фреймворк для тех, кому не нужны рельсы для разработки API.
Вы считаете, что это плохо, когда существует несколько способов решить одну и ту же задачу?
Другие покупают стройматериалы, делают проект, льют фундамент и.т.д.
Не имею ничего против ни первых, ни вторых. Просто люди по-разному получают фан.
Насчет замены sass на stylus ради ускорения компиляции — gulp-sass использует для компиляции node-реализацию процессора, libsass. Отрабатывает практически моментально даже на здоровенных файлах.
К нему можно добавить compass с помощью bower-пакета compass-mixins, специально созданного для замены ruby-compass в libsass.
Жаль, что не была затронута тема инкрементальных билдов.
Бесплатно доступна Starter Edition. Обычная стоит $30, Full edition $70
book.discovermeteor.com/chapter/github — отсюда начинаются платные главы, т.е. бесплатных там четыре главы включая введение.
Вот я все хочу попробовать, но никак не могу побороть ощущение, что это такая «вещь в себе»
Я в первую очередь хотел показать, как можно жить без Rails и не отказывать себе ни в чем, хотя бы а рамках написания API.
Из-за специфики кода Grape его нелья перезагружать просто выгрузкой объявленных констант и повторным require изменившегося файла.
Когда я начал свои изыскания в этом вопросе, я первым делом прицепил Grape к Padrino, у которого достаточно неплохой релоадер. Это сработает в определенных пределах — простое приложение типа этого HelloWorld будет перезагружаться, но начнут задваиваться роуты — это можно увидеть подключив grape-swagger. Потом я попытался пропатчить Grape::API, чтобы заставить его нормально работать с Padrino::Reloader — то, что получилось в итоге, по времени релоада мало отличалось от shotgun.
Поэтому я написал отдельный гем, который делает это с учетом специфики Grape — он делает кучу манки-патча Grape::API класса для dev-окружения.
?
Вы же знаете, что необязательно релизить гем, чтобы его в Gemfile прицепить?