Комментарии 28
Хочется добавить про волшебную команду bundle console, которая запускает irb с уже загруженным гемом.
Проверять работоспособность нужно тестами, а не в консоли.
Бейдж Travis CI для гема без тестов выглядит по меньшей мере странно. Для чего он?
Собственно я сначала задался вопросом, почему вопрос тестирования в статье пропущен, потом глянул репозиторий — стало понятно.
Ну и в принципе версионирование без тестирования регрессии попахивает.
Собственно я сначала задался вопросом, почему вопрос тестирования в статье пропущен, потом глянул репозиторий — стало понятно.
Ну и в принципе версионирование без тестирования регрессии попахивает.
Я указал, что гем развивается. Просто, конкретно я сам, не использовал TDD. Но сейчас как раз занимаюсь тестами. Гем сыроват, так что все делаю по порядку. Он был нужен для быстрого решения задачи. С этим он справился. В следующем релизе уже будет RSpec)
Гем пускай развивается, это правильно. Но какой смысл релизить гем, который даже не бета?
Вы же знаете, что необязательно релизить гем, чтобы его в Gemfile прицепить?
Вы же знаете, что необязательно релизить гем, чтобы его в Gemfile прицепить?
Знаю. Так и делал по началу. Но свелось к тому, что нужно было его использовать не на локальной машине. И в итоге принял решение сделать все вот так.
А чем не устроило
?
gem "gem-i-create", github: "mynameis/mygem"
?
Та вроде надо же обновлять его постоянно через bundle. Я изначально использовал path: и настроил SFTP с development сервером. Но это было не так удобно. Я понимаю, что это немного неправильный подход, но опять таки повторюсь, что изначально юзал для своих задач. И уже после задумался над его продвижением и развитием. Все же, спасибо большое за замечание, я их обязательно учту в следующих релизах и в будущем =)
Если гем всё-таки покинул локалхост и пошёл хотя бы в тестовое окружение, а уж тем более в продакшн, то указывать github в гемфайле не очень хорошо, так как в итоге остаётся привязка к репозиторию конкретного пользователя и если он уволился из компании и переименует/удалит репку, то будут проблемы. С RubyGems же удалить что-либо очень сложно.
Я имел в виду для целей тестирования во время разработки и интеграции в другие приложения) Я указывал сугубо в своем же прототипе.
А засорять rubygems непротестированными бета-версиями это отличный план, ага.
Ну пусть это будет гитхаб компании, какие проблемы-то?
Ну и ещё вариант — использовать какой-нибудь GemFury и публиковать гемы в свой приватный репозиторий, зачем их на паблик-то недоделанные такие светить? (Ну и плюс гемы не только общедоступные бывают...)
Ну и ещё вариант — использовать какой-нибудь GemFury и публиковать гемы в свой приватный репозиторий, зачем их на паблик-то недоделанные такие светить? (Ну и плюс гемы не только общедоступные бывают...)
Прощу прощения, не хотел призывать к захламлению RubyGems недоделками. Как писал выше, имел цель сказать, что если есть минимальный функционал, достойный первой версии, то его стоит выложить в открытый доступ, конечно же если политика компании позволяет и нет прочих ограничений.
В том была одна из целей. Предоставить его общественности. Никто же не засталяет людей использовать его, но если он их заинтересовал, то почему бы и нет.
Вот еще одна соль в том, что там скрывать то нечего. Он будет развиваться, а там может еще какие контрибьюторы подтянуться. В этом то суть опен-сорса.
Вот еще одна соль в том, что там скрывать то нечего. Он будет развиваться, а там может еще какие контрибьюторы подтянуться. В этом то суть опен-сорса.
.
Сугубо личное мнение, но всё же: для написания гемов вполне хватает 'bundle gem' и примеров исходников хороших уже существующих гемов (для RoR — это, например, rubocop; как бонус мы получаем хороший кодстандарт от товарища bbatsov). Если в существующих гемах ничего не понятно, то и свой лучше не писать по вполне понятным причинам. А если понятно, то и руководства другого не нужно.
В целом, не могу не согласиться. Но всплывает вопрос. Если вам нужно реализовать какую-то кастомную фичу, или же подход используемый в существующем решении вас не совсе устраивает, то разве вы не станете пытаться сделать свою реализацию?) Есть вариант делать обертки для существующих решений, но думаю в полне очевидно, что это чистой воды костыль.
P.S:Надеюсь, я правильно понял ваш комментарий.
P.S:Надеюсь, я правильно понял ваш комментарий.
Не совсем, я имел в виду саму структуру гема, способ организации файлов и способы патча уже существующих библиотек. Например, кто-то из старообрядцев пишет версию прямо в gemspec, кто-то использует init.rb в корне гема, кто-то пишет весь код внутри единственного файла 'lib/gem-name.rb', да и ещё много чего. Про реализацию самого функционала ничего говорить не хочу, ибо это уже творчество, которое сильно зависит от автора и его хода мыслей.
Вот с этим полностью согласен. Потому что видел пару случаев когда все описано в «lib/gem-name.rb». Считаю, что если гем реализует чуть более чем один вид функционала, то лучше разносить. Хотя я думаю, что и так оно неплохо работает)
Вы правы, если гем реализует чуть больше, чем один вид функционала, то это два гема. Швейцарские ножи среди гемов — это редкий зверь сомнительной ценности.
Ещё не хватает кодстандарта для гемов, а очень хотелось бы что-то типа такого. Сам, если что-то надо, читаю исходники популярных гемов, но, подозреваю, у начинающих с этим проблемы.
Ещё не хватает кодстандарта для гемов, а очень хотелось бы что-то типа такого. Сам, если что-то надо, читаю исходники популярных гемов, но, подозреваю, у начинающих с этим проблемы.
А еще файлы и директории должны именоваться в
snake_case, т.е. не SomeCoolGem.rb, а some_cool_gem.rb.Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почти полное руководство по написанию Ruby гемов