Комментарии 51
Вот знаете в чем проблема Yeoman? В том что встречаются мертвые генераторы или генератор который вроде все развернул и даже работает но на гите висит 40 багов и тесты вообще не работают. Желания разбираться в чем причина при учете что автор просто «забил» вообще нет. (Причем генератор популярный).
+3
Это проблема всего Open Source в целом.
Что вы хотите, бесплатный сыр и без мышеловки? Люди занимаются Open Source тогда, когда есть возможность.
По сему, не судите строго. А ещё лучше — вносите свой посильный вклад.
Что вы хотите, бесплатный сыр и без мышеловки? Люди занимаются Open Source тогда, когда есть возможность.
По сему, не судите строго. А ещё лучше — вносите свой посильный вклад.
+12
Да есть такое дело. Но обидно что вроде вещь отличная есть люди кто готов поправить проблемы и я в их числе. Ну да ладно.
0
Разве не в репозиториях хранятся исходники генераторов? Тогда можно было бы написать автору и попросить его включить вас в качестве контрибьютора. Или Pull-request с изменениями отправить.
0
Делаете форк, фиксите баги, юзаете свою же версию. Или, как уже посоветовали, отправляете PR.
+1
Да сделал я так, чего вы накинулись :)
Просто обидно что «мертвые» репозитории в топе и нету модерации жесткой.
Просто обидно что «мертвые» репозитории в топе и нету модерации жесткой.
+1
Вы бы с этого начинали :-)
Просто тут могли подумать, что вам не нравится Open Source.
Просто тут могли подумать, что вам не нравится Open Source.
0
Да я думал уже вымерли те кому не нравится Open Source как таковой.
0
Имеете в виду Microsoft? :-)
0
А с каких пор MS'у не нравится Open Source? Неужто с того самого момента как они начали выкладывать многие свои наработки в открытый доступ?
0
Возможно. Но сколько лет они этого не делали? Исходный код главного детища всё равно под семью замками.
0
А с каких пор MS'у не нравится Open Source?
С момента рождения MS, очевидно. Первые попытки «поиграть» в Open Source еще не говорят о том, что завтра они продолжат показывать эту «любовь». Давайте подождем хотя бы лет 5, посмотрим.
0
Видимо проблема не в оперсорсе, а в модерации и ранжировании генераторов. Авторов надо поощрять поддерживать свое детище в актуальном состоянии. Иначе будет свалка где на один работающий будет десять неработающих
0
Отличный инструмент.
Недавно начал делать скаффолдер для REST API на основе Sails. Теперь разворачиваю настроенное API с оптимизациями и с готовой авторизацией через JWT + bcrypt за полминуты.
Вот думаю, продолжить это дело и дополнить скаффолдер еще фабриками для отправок писем, смс, работы с амазоном и т.д. Чтобы при разворачивании проекта оставалось только API ключи прописать.
Недавно начал делать скаффолдер для REST API на основе Sails. Теперь разворачиваю настроенное API с оптимизациями и с готовой авторизацией через JWT + bcrypt за полминуты.
Вот думаю, продолжить это дело и дополнить скаффолдер еще фабриками для отправок писем, смс, работы с амазоном и т.д. Чтобы при разворачивании проекта оставалось только API ключи прописать.
0
Это интересно. Вы выложили его в главный репозиторий Yeoman?
0
Да, он там уже есть и пока только под версией 0.1.0, которая делает просто разворачивание проекта. В 0.2.0 включится автоматическая установка зависимостей, готовая фабрика для cipher'ов и интегрирован passport с возможностью делать локальную авторизацию по username\password паре и Facebook с Twitter токенами.
Исходники — клац
Название в репозитории yeoman — sails-rest-api.
ЗЫ. Отличительной чертой данного скаффолдера является уже настроенный Sails для работы с REST API. То есть, там уже выключены все ненужные хуки и функционал вроде Grunt, views и подобные. Получаете только чистый backend в виде API.
Исходники — клац
Название в репозитории yeoman — sails-rest-api.
ЗЫ. Отличительной чертой данного скаффолдера является уже настроенный Sails для работы с REST API. То есть, там уже выключены все ненужные хуки и функционал вроде Grunt, views и подобные. Получаете только чистый backend в виде API.
+1
Не холивара ради, просто любопытно.
Почему выбрали Sails? С чем (из nodejs) сравнивали? Чем привлекло?
Почему выбрали Sails? С чем (из nodejs) сравнивали? Чем привлекло?
0
По количеству коммитов и активных контрибьюторов Sails пока на первом месте.
Также очень радует его ODM Waterline, которая работает просто прекрасно и уровень абстракции очень хороший.
Также очень радует его ODM Waterline, которая работает просто прекрасно и уровень абстракции очень хороший.
0
На втором. Express по очевидным причинам на первом.
Вы имели ввиду ORM? Пробовали Sequelize?
Вы имели ввиду ORM? Пробовали Sequelize?
0
Sails построен на Express. Радуют его blueprints, которые с коробки генерируют все REST роуты, есть policies, где можно писать ACL. На Express это пришлось бы делать все самому.
Нет, я имел ввиду именно ODM (Object Document Mapper), в то время как ORM — это Object Relation Mapper. А так как Mongo — это документо-ориентированная, то логичнее считать Waterline ODM. Правда это спорный вопрос, так как Waterline поддерживает и ORM :)
Нет, я имел ввиду именно ODM (Object Document Mapper), в то время как ORM — это Object Relation Mapper. А так как Mongo — это документо-ориентированная, то логичнее считать Waterline ODM. Правда это спорный вопрос, так как Waterline поддерживает и ORM :)
0
Забыл отправить комментарий пару дней назад.
Спасибо. Действительно, перечисленное это фундаментальные аспекты которые могу повлиять на выбор.
Коллега год назад с Sails.js работал. Хотел перейти с Express. Докладывал что встречал кучу трудностей.
Интересно просто как сейчас.
На сайте пишут что все отлично, только так всегда. Пока с людьми которые использовали не поговоришь, ничего не узнаешь.
Мне к примеру очень нравится hapi.js но его фундаментальный и жирный минус в том, что нужно очень много писать самостоятельно и рыться чуть ли не в исходниках, потому что много чего меняется (в лучшую сторону) но все равно нужно за этим следить.
ORM / ODM… думал это опечатка просто.
Думаю нас еще ждет в ближ. пару лет терминологическая неразбериха с ORM / ODM / OGM / O WTF M
CAP ограничения порождают разные классы БД с разными tradeoff так что будет много желающих
посидеть на всех стульях / придумать свой велосипед OFTWM :)
Спасибо. Действительно, перечисленное это фундаментальные аспекты которые могу повлиять на выбор.
Коллега год назад с Sails.js работал. Хотел перейти с Express. Докладывал что встречал кучу трудностей.
Интересно просто как сейчас.
На сайте пишут что все отлично, только так всегда. Пока с людьми которые использовали не поговоришь, ничего не узнаешь.
Мне к примеру очень нравится hapi.js но его фундаментальный и жирный минус в том, что нужно очень много писать самостоятельно и рыться чуть ли не в исходниках, потому что много чего меняется (в лучшую сторону) но все равно нужно за этим следить.
ORM / ODM… думал это опечатка просто.
Думаю нас еще ждет в ближ. пару лет терминологическая неразбериха с ORM / ODM / OGM / O WTF M
CAP ограничения порождают разные классы БД с разными tradeoff так что будет много желающих
посидеть на всех стульях / придумать свой велосипед OFTWM :)
0
Посмотрел на Sequelize. Это же чисто ORM. Нету поддержки документо-ориентированных БД.
0
Будет здорово, если появится подобный краткий обзор по Grunt/Gulp, т.к. эта заметка получилась очень лёгкой и информативной, спасибо.
+1
Обожаю angular-fullstack. Единственное: grunt крутой, но медленный.
+1
Хм, с gulp + webpack больше заморочек, но он гораздо быстрее.
+1
О каких именно заморочках идёт речь?
0
Синхронизацию потоков — построение цепочек с зависимостями, возвращение и объединение, мало кто понимает.
А так у меня были наброски более-менее нормального Seed'а под Gulp.
А так у меня были наброски более-менее нормального Seed'а под Gulp.
0
Спасибо за статью. Давно слышал что такое есть, но не было времени пощупать. Кстати, это ок установленный локально yeoman генераторы устанавливает глобально?
0
Ценность всего этого дела видимо только в генераторах шаблонов. Если же сам шаблон проекта мне не подходит — выходит нужно писать свой генератор. Да только зачем мне писать генератор если шаблон у меня уже есть? Разве что для того чтоб с другими им поделится. Мне кажется достаточно было бы создать каталог шаблонов проектов с описаниями в одном формате. Это реализовать проще, и авторам легче добавлять в каталог свои шаблоны (не нужно разбираться с тем как генератор написать), и нагляднее для разработчиков (сразу видно не генератор, а итоговый результат).
+4
Плюс возможности совместить целый из нескольких простых изолированных шаблонов.
+6
В генераторе вы можете свой «шаблон» кастомизировать каким-нибудь образом через опции (имя приложения задать, имя модулей, зависимости разные подключать по необходимости, сторонние сервисы и т.д.). Имея просто шаблон кода — его нужно будет под новый проект менять вручную (в зависимости от нужд). У нас в компании написан свой генератор проектов на yo, и у нас там примерно 15 разных вопросов во время генерации (каждый из которых, в конечном итоге, что-то меняет в сгенерённом коде). Но у нас часто стартуют проекты (и их довольно много), можно сказать, специфичный случай, поэтому в этом есть смысл.
+2
Странная тулза.
А я просто дербаню куски из папки с соседним проектом — выходит довольно быстро. Ну и `npm init` там.
А тут — сначала изучи как пользоваться яманом, потом изучи какие генераторы есть, потом изучи что генератор может нагенерировать, потом проверь рабочее ли все это, потом изучи структуру нагенерированного — подходит ли под привычный флоу.
Так если надо автоматизировать по 5 проектов в день — может и ок. Но вообще это же одноразовая операция.
А я просто дербаню куски из папки с соседним проектом — выходит довольно быстро. Ну и `npm init` там.
А тут — сначала изучи как пользоваться яманом, потом изучи какие генераторы есть, потом изучи что генератор может нагенерировать, потом проверь рабочее ли все это, потом изучи структуру нагенерированного — подходит ли под привычный флоу.
Так если надо автоматизировать по 5 проектов в день — может и ок. Но вообще это же одноразовая операция.
+7
Кажется, идея yeoman в том, чтобы оформить шаблон под собственный флоу и выпускать на нем проекты как на конвеере.
Если новые проекты нужно начинать не так часто, как выходят новые инструменты (вроде grunt или gulp), то можно обойтись и без yeoman
Если новые проекты нужно начинать не так часто, как выходят новые инструменты (вроде grunt или gulp), то можно обойтись и без yeoman
0
Ну вот вы всё правильно пишете, это для тех, кто лабает по 10 сайтов в день по 500 рублей.
Если у вас один проект раз в полгода — проходите мимо.
Если у вас один проект раз в полгода — проходите мимо.
+1
НЛО прилетело и опубликовало эту надпись здесь
Мне пригождается, когда нужно делать что-то на новом стеке. Я вот все равно не знаю, как лучше сконфигурировать проект под незнакомый мне фреймворк, а изучать приходится. Так легче взять что-то готовое и разобраться что мне там подходит, а что нет, чем с нуля копаться и набивать шишки. Ну и по ходу копирую генератор (чтобы не затерлось при обновлении) и вношу свои изменения на будущее для этого стека.
0
Местами оно вроде ок, но мне недавно «понадобилось» webapi на c# — сгенерил хрень.
0
По-моему самое интересное в yeoman даже не генерация шаблона всего приложения целиком. Как тут уже сказали, это разовая операция и писать под нее такую мощную утилиту было бы странно. Главное, что yeoman может генерировать отдельные части уже созданного приложения, те же контроллеры, например. Вот наглядный пример из офф документации:
Это действительно может помочь в ежедневной рутине, если модули приложения имеют сложную, но схожую структуру.
$ yo angular:controller myController
$ yo angular:directive myDirective
$ yo angular:filter myFilter
$ yo angular:service myService
Это действительно может помочь в ежедневной рутине, если модули приложения имеют сложную, но схожую структуру.
+2
Согласен с вами. Иногда не нужно генерить целиком весь проект, достаточно одного контроллера или модели.
0
Да, есть хорошие генераторы типа github.com/Swiip/generator-gulp-angular и это то, чего очень не хватает.
0
НЛО прилетело и опубликовало эту надпись здесь
Спасибо, заинтересовало
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Yeoman для новичков