Да. Вы правы. Я тоже помню когда GL был еще на gitolite. Но как по мне, если реально нужен подобный инструмент, то gitolite — пережиток прошлого, ИМХО.

Я использовал для pet'ов Bitbucket, но по ощущениям как-то GitLab приятнее. Хотя я не нашел супер-отличий. Может дело в том, что Atlassian это все таки по большей части enterprise сегмент, и в нем мало духа авантюризма)

На GitLab мы не так давно переехали, и пока очередной переезд точно не грозит. Но для себя я точно Gogs изучу.
А если не секрет, что именно сподвигло уйти с gitlab'a?

Честно говоря, не сталкивался с этой проблемой. Надо будет подробнее изучить. Но я сомневаюсь, что этот вопрос никогда не поднимался. Если что найду — отпишу)

Нашими молитвами и одминскими бубнами)

Теперь понемногу становится понятно, откуда идея для логотипа Хабра))

Дико извиняюсь, если мои вопросы уже были раскрыты в комментах, но лень-матушка переборола над поиском во всех комментариях.

1. Зачем на production-сервере использовать Ubuntu. Ведь намного удобнее CentOS, или тот же самый Debian?

2. Насчет Vagrant. Если использовали, то в чем профит после поднятия сервера? То есть, вы же не дропаете сервер каждое утро и не поднимаете его с нуля.

3. Лично вас, устраивает RVM на сервере? Просто я не заметил особых недостатков в его использовании не на машине для локал-девелопмента.

Отличная статья! Но немного рябит в глазах, когда на экране кусок текста в один абзац и сверху + снизу разные анимации. Немного ощущение, что попал на сайт от Ucoz несколько лет назад :)

Это я знаю. Провтыкал спецификацию. Извиня.сь перед всеми, кто перенял эту мою ошибку.

Вы уже донесли мою мысль. Спасибо большое)

В том была одна из целей. Предоставить его общественности. Никто же не засталяет людей использовать его, но если он их заинтересовал, то почему бы и нет.

Вот еще одна соль в том, что там скрывать то нечего. Он будет развиваться, а там может еще какие контрибьюторы подтянуться. В этом то суть опен-сорса.

Как один из их числа, не могу с вами не согласиться)

Вот с этим полностью согласен. Потому что видел пару случаев когда все описано в «lib/gem-name.rb». Считаю, что если гем реализует чуть более чем один вид функционала, то лучше разносить. Хотя я думаю, что и так оно неплохо работает)

В целом, не могу не согласиться. Но всплывает вопрос. Если вам нужно реализовать какую-то кастомную фичу, или же подход используемый в существующем решении вас не совсе устраивает, то разве вы не станете пытаться сделать свою реализацию?) Есть вариант делать обертки для существующих решений, но думаю в полне очевидно, что это чистой воды костыль.

P.S:Надеюсь, я правильно понял ваш комментарий.

Я имел в виду для целей тестирования во время разработки и интеграции в другие приложения) Я указывал сугубо в своем же прототипе.

Та вроде надо же обновлять его постоянно через bundle. Я изначально использовал path: и настроил SFTP с development сервером. Но это было не так удобно. Я понимаю, что это немного неправильный подход, но опять таки повторюсь, что изначально юзал для своих задач. И уже после задумался над его продвижением и развитием. Все же, спасибо большое за замечание, я их обязательно учту в следующих релизах и в будущем =)

Знаю. Так и делал по началу. Но свелось к тому, что нужно было его использовать не на локальной машине. И в итоге принял решение сделать все вот так.

.

Я указал, что гем развивается. Просто, конкретно я сам, не использовал TDD. Но сейчас как раз занимаюсь тестами. Гем сыроват, так что все делаю по порядку. Он был нужен для быстрого решения задачи. С этим он справился. В следующем релизе уже будет RSpec)