А я наоборот часто слышал такое высказывание среди рубистов :)

Вы всегда можете отправить Pull Request ;)

Не скромная такая экономия получается. И, кстати, не только на этом экономите. На днях таким образом из postgresql вытащил большой json за ~ 5 ms вместо 180 ms в случае с acts_as_api + сериализация.

А почему риторический? История говорит об обраном

git-flow как раз так и развивается. Кстати очень активно :)

Суть была в том, чтобы некоторые фичи внедрять при материальной поддержке.

Делайте платный саппорт. Не убивайте опенсорс.

Так мы этим и занимаемся :))) И мы не жаловались )))

1. По поводу коммантария, содержимое его было скорее как «Почему вы игнорируете общепринятые правила хорошего тона?». Чем плоха критика? Или нужно писать «Ой, вы кажется тут плохо написали… что если сделать вот так?» Бред!

2. Профессионал всегад сразу поймет о чем речь идет (не упрекаю Дмитрия в непрофессионализме, его уровень весьма высок и заслуживает уважения.). Там был намек, что это должно быть не там. Давайте еще по каждому чиху будем создавать Issue. Комментирование кода на гитхабе как раз и предназначено для целей ревью кода. Замечания никогда не были приятными. Мы можем этого не делать, если это не по душе.

3.

+


4. Мы неоднократно присылали PR содержащие рефакторинг.

5. Мы постоянно пишем разработчикам с предложеиями о том, как можно сделать «по-другому». И часто делаем это в кулуарах. Написали в паблике — все, караул?

6. Мы адекватно воспринимаем, когда наши решения также критикуют.

7. Мы всегда готовы оказать посильную помощь. Об этом неоднократно сообщалось.

В чужом глазу соринку видно, а в своём и бревна не видать.

Парни, давайте не будем жаловаться на жизнь. Мужики собрались ведь.

Оперсорс хорош тем, что делает вас еще более крутыми спецами. Не смоотря на то, насколько круты вы сейчас.

Я тоже видел этот комментарий. И мне кажется вы не проникли сутью проблемы, ибо такие вещи просто так не исправить.

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

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

Большинство опенсорс проектов родились по прнципу «сделал себе, поделился с сообществом».

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

Вклад всегда останется в истории.

Да, да, мне стоит поправиться, ибо не корректно выразил свою мысль. В реалиях обычно не стоит задача бекапа кода сайта :)

Т.е. всякие там файлы, фотки, аватарки юзеры не заливают?

А как обстоит дело с удаленным размещением файлов, фоток, аватарок? Или у вас не встречалось ситуации с несколькими фрондами для исполнения кода сайта?

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

А кто говорит, что мы так не делаем? ;)

На самом деле, есть ряд мест, которые стоит там «прилизать». Что очень радует, парни очень адекватные и правильно реагируют на критику и следят за чистотой кода.

devise хорош до момента кастомизации

Для меня ответ «по-умолчанию выключен» == «отсутствует», ибо пользы и понта от него никакого, так как толпы пользователей загнать в настройки и что-то там сделать для «того, чтобы у них кое-что заработало» практически нереально.

Я даже не думал с вами спорить :) надеюсь сопоставление «терминологии» окажутся полезными не только нам :)

Я возможно недосказал. Если я не ошибаюсь, то где-то было красиво сказано waterfall methodology is a description of the natural, and the most dangerous approach to the management of projects, but do not sew the fly's trunk (мог допустить ошибку, ибо по памяти). Другие методологии могут быть эволюционированием или комбинированием. Взглянем на тот же MSF.

Это я к тому, что не может проект выжить без применения какой либо методологии и вполне естественно, если по дефолту будет водопад:

. Пришел заказчик, высказал пожелания
… Команда села, подумала
…… Уточнили все детали
……… Сели делать и сделали
………… Сдали.

Согласен, при малом опыте у команды — будут итерации, вполне оправданные, но, не хочу накручивать, вполне естественно, что по дефолту упоминается водопадная модель.

К тому же, про отрицание всех методологий я не говорил. Я сразу уточнил, что речь идет именно о какой-то конкретной методологии, а не о всех сразу. Это так, если уж цепляться к словам.