Комментарии 51
Вот знаете в чем проблема Yeoman? В том что встречаются мертвые генераторы или генератор который вроде все развернул и даже работает но на гите висит 40 багов и тесты вообще не работают. Желания разбираться в чем причина при учете что автор просто «забил» вообще нет. (Причем генератор популярный).
Это проблема всего Open Source в целом.
Что вы хотите, бесплатный сыр и без мышеловки? Люди занимаются Open Source тогда, когда есть возможность.
По сему, не судите строго. А ещё лучше — вносите свой посильный вклад.
Что вы хотите, бесплатный сыр и без мышеловки? Люди занимаются Open Source тогда, когда есть возможность.
По сему, не судите строго. А ещё лучше — вносите свой посильный вклад.
Да есть такое дело. Но обидно что вроде вещь отличная есть люди кто готов поправить проблемы и я в их числе. Ну да ладно.
Разве не в репозиториях хранятся исходники генераторов? Тогда можно было бы написать автору и попросить его включить вас в качестве контрибьютора. Или Pull-request с изменениями отправить.
Делаете форк, фиксите баги, юзаете свою же версию. Или, как уже посоветовали, отправляете PR.
Да сделал я так, чего вы накинулись :)
Просто обидно что «мертвые» репозитории в топе и нету модерации жесткой.
Просто обидно что «мертвые» репозитории в топе и нету модерации жесткой.
Вы бы с этого начинали :-)
Просто тут могли подумать, что вам не нравится Open Source.
Просто тут могли подумать, что вам не нравится Open Source.
Да я думал уже вымерли те кому не нравится Open Source как таковой.
Имеете в виду Microsoft? :-)
А с каких пор MS'у не нравится Open Source? Неужто с того самого момента как они начали выкладывать многие свои наработки в открытый доступ?
Возможно. Но сколько лет они этого не делали? Исходный код главного детища всё равно под семью замками.
А с каких пор MS'у не нравится Open Source?
С момента рождения MS, очевидно. Первые попытки «поиграть» в Open Source еще не говорят о том, что завтра они продолжат показывать эту «любовь». Давайте подождем хотя бы лет 5, посмотрим.
Видимо проблема не в оперсорсе, а в модерации и ранжировании генераторов. Авторов надо поощрять поддерживать свое детище в актуальном состоянии. Иначе будет свалка где на один работающий будет десять неработающих
Отличный инструмент.
Недавно начал делать скаффолдер для REST API на основе Sails. Теперь разворачиваю настроенное API с оптимизациями и с готовой авторизацией через JWT + bcrypt за полминуты.
Вот думаю, продолжить это дело и дополнить скаффолдер еще фабриками для отправок писем, смс, работы с амазоном и т.д. Чтобы при разворачивании проекта оставалось только API ключи прописать.
Недавно начал делать скаффолдер для REST API на основе Sails. Теперь разворачиваю настроенное API с оптимизациями и с готовой авторизацией через JWT + bcrypt за полминуты.
Вот думаю, продолжить это дело и дополнить скаффолдер еще фабриками для отправок писем, смс, работы с амазоном и т.д. Чтобы при разворачивании проекта оставалось только API ключи прописать.
Это интересно. Вы выложили его в главный репозиторий Yeoman?
Да, он там уже есть и пока только под версией 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.
Не холивара ради, просто любопытно.
Почему выбрали Sails? С чем (из nodejs) сравнивали? Чем привлекло?
Почему выбрали Sails? С чем (из nodejs) сравнивали? Чем привлекло?
По количеству коммитов и активных контрибьюторов Sails пока на первом месте.
Также очень радует его ODM Waterline, которая работает просто прекрасно и уровень абстракции очень хороший.
Также очень радует его ODM Waterline, которая работает просто прекрасно и уровень абстракции очень хороший.
На втором. Express по очевидным причинам на первом.
Вы имели ввиду ORM? Пробовали Sequelize?
Вы имели ввиду ORM? Пробовали Sequelize?
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 :)
Забыл отправить комментарий пару дней назад.
Спасибо. Действительно, перечисленное это фундаментальные аспекты которые могу повлиять на выбор.
Коллега год назад с 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 :)
Посмотрел на Sequelize. Это же чисто ORM. Нету поддержки документо-ориентированных БД.
Будет здорово, если появится подобный краткий обзор по Grunt/Gulp, т.к. эта заметка получилась очень лёгкой и информативной, спасибо.
Обожаю angular-fullstack. Единственное: grunt крутой, но медленный.
Хм, с gulp + webpack больше заморочек, но он гораздо быстрее.
О каких именно заморочках идёт речь?
Синхронизацию потоков — построение цепочек с зависимостями, возвращение и объединение, мало кто понимает.
А так у меня были наброски более-менее нормального Seed'а под Gulp.
А так у меня были наброски более-менее нормального Seed'а под Gulp.
Спасибо за статью. Давно слышал что такое есть, но не было времени пощупать. Кстати, это ок установленный локально yeoman генераторы устанавливает глобально?
Ценность всего этого дела видимо только в генераторах шаблонов. Если же сам шаблон проекта мне не подходит — выходит нужно писать свой генератор. Да только зачем мне писать генератор если шаблон у меня уже есть? Разве что для того чтоб с другими им поделится. Мне кажется достаточно было бы создать каталог шаблонов проектов с описаниями в одном формате. Это реализовать проще, и авторам легче добавлять в каталог свои шаблоны (не нужно разбираться с тем как генератор написать), и нагляднее для разработчиков (сразу видно не генератор, а итоговый результат).
Плюс возможности совместить целый из нескольких простых изолированных шаблонов.
В генераторе вы можете свой «шаблон» кастомизировать каким-нибудь образом через опции (имя приложения задать, имя модулей, зависимости разные подключать по необходимости, сторонние сервисы и т.д.). Имея просто шаблон кода — его нужно будет под новый проект менять вручную (в зависимости от нужд). У нас в компании написан свой генератор проектов на yo, и у нас там примерно 15 разных вопросов во время генерации (каждый из которых, в конечном итоге, что-то меняет в сгенерённом коде). Но у нас часто стартуют проекты (и их довольно много), можно сказать, специфичный случай, поэтому в этом есть смысл.
Странная тулза.
А я просто дербаню куски из папки с соседним проектом — выходит довольно быстро. Ну и `npm init` там.
А тут — сначала изучи как пользоваться яманом, потом изучи какие генераторы есть, потом изучи что генератор может нагенерировать, потом проверь рабочее ли все это, потом изучи структуру нагенерированного — подходит ли под привычный флоу.
Так если надо автоматизировать по 5 проектов в день — может и ок. Но вообще это же одноразовая операция.
А я просто дербаню куски из папки с соседним проектом — выходит довольно быстро. Ну и `npm init` там.
А тут — сначала изучи как пользоваться яманом, потом изучи какие генераторы есть, потом изучи что генератор может нагенерировать, потом проверь рабочее ли все это, потом изучи структуру нагенерированного — подходит ли под привычный флоу.
Так если надо автоматизировать по 5 проектов в день — может и ок. Но вообще это же одноразовая операция.
Кажется, идея yeoman в том, чтобы оформить шаблон под собственный флоу и выпускать на нем проекты как на конвеере.
Если новые проекты нужно начинать не так часто, как выходят новые инструменты (вроде grunt или gulp), то можно обойтись и без yeoman
Если новые проекты нужно начинать не так часто, как выходят новые инструменты (вроде grunt или gulp), то можно обойтись и без yeoman
Ну вот вы всё правильно пишете, это для тех, кто лабает по 10 сайтов в день по 500 рублей.
Если у вас один проект раз в полгода — проходите мимо.
Если у вас один проект раз в полгода — проходите мимо.
НЛО прилетело и опубликовало эту надпись здесь
Мне пригождается, когда нужно делать что-то на новом стеке. Я вот все равно не знаю, как лучше сконфигурировать проект под незнакомый мне фреймворк, а изучать приходится. Так легче взять что-то готовое и разобраться что мне там подходит, а что нет, чем с нуля копаться и набивать шишки. Ну и по ходу копирую генератор (чтобы не затерлось при обновлении) и вношу свои изменения на будущее для этого стека.
Местами оно вроде ок, но мне недавно «понадобилось» webapi на c# — сгенерил хрень.
По-моему самое интересное в yeoman даже не генерация шаблона всего приложения целиком. Как тут уже сказали, это разовая операция и писать под нее такую мощную утилиту было бы странно. Главное, что yeoman может генерировать отдельные части уже созданного приложения, те же контроллеры, например. Вот наглядный пример из офф документации:
Это действительно может помочь в ежедневной рутине, если модули приложения имеют сложную, но схожую структуру.
$ yo angular:controller myController
$ yo angular:directive myDirective
$ yo angular:filter myFilter
$ yo angular:service myService
Это действительно может помочь в ежедневной рутине, если модули приложения имеют сложную, но схожую структуру.
Согласен с вами. Иногда не нужно генерить целиком весь проект, достаточно одного контроллера или модели.
Да, есть хорошие генераторы типа github.com/Swiip/generator-gulp-angular и это то, чего очень не хватает.
НЛО прилетело и опубликовало эту надпись здесь
Спасибо, заинтересовало
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Yeoman для новичков