Разговор ни о чем. Вы спросили чужое мнение, а теперь кому-то пытаетесь доказать, что ваше мнение — правильное.
--
Речь не идет о «ставить в проект все попало, а потом полгода решать возникшие проблемы». Речь даже не идет о смене paperclip'a, например, на carrierwave.
Речь идет о том, что в свой следующий проект я хочу вставить carrierwave, а не paperclip, хотя последний отлично решает все мои задачи. Я хочу использовать ancestry, а не acts_as_tree например (или nested_set). И я хочу, чтобы работодатель позаботился о том, чтобы мне не нужно было мучаться из-за неосуществленной мечты.
Есть люди, которые 10 лет назад научились «делать сайтики на php», и до сих пор их делают так же. Они верстают таблицами, они презирают все новое: они получают заказы и деньги и рады этому.
В руби-/рельсо-мире таких, имхо, меньшинство. К счастью.
--
Andrey Ognevsky
On Sunday, June 19, 2011 at 12:21 PM, splyeff@gmail.com wrote:
Я не говорю о том, что есть объективная необходимость смены версии рельсов
или обновления софта. Есть множество людей, способных поддерживать любой
код. Им вообще без разницы, лишь бы деньги платили. А есть люди, для которых
это важно. Это вопрос чисто субъективный, ещё раз повторюсь.
В принципе, теперь такой взгляд на постоянное обновление стал понятен.
Это можно даже свести к внутриорганизационному пиару, одному из
методов повышению мотивации сотрудников. В одних команиях проводят в
семинары по новым технологиям, другие ставят теннисные столы, чтобы
можно было развлечься в рабочее время. А в данном случае можно
сказать, что в качестве такого развлечения становится постоянное
обновление используемых в разрабатываемом продукте компонентов. Если
получается, что затраты времени или денег на это остаются такого же
порядка, как и в классических вариантах мотивации сотрудников, то да,
этот способ ничем не хуже для результата, чем остальные.
Но есть ощущение, что такой подход может работать только в случае
участия в проекте одного разработчика или в маловероятных ситуациях,
когда участников много, но все имеют такую наклонность. Я бы,
например, стал вешаться, если из-за обновления компонента пришлось бы
тратить много времени на скучное вылавливание проблем и переписывание
старого кода, вместо написания кода нового и неизведанного :)
Со sles 9 пример все-таки уже не совсем про новое и неизведанное. В
этом случае нашлась возможность без ущерба для существующей части
представить отдельный сервер с требуемой версией. Часто это
невозможно. Например, если нужно встроить небольшой модуль в большой
многолетний проект. Переносить его на новый дебиан и потратить сотню
часов других разработчиков будет менее рационально, чем адаптировать
этот модуль за семь часов.
--
--
Данное сообщение отправлено Вам, так как Вы являетесь подписчиком группы "RubyOnRails to russian" на группах Google.
FAQ группы находится по адресу: http://ru.wikibooks.org/wiki/RubyFAQ
Для того, чтобы отправить сообщение в эту группу, пошлите его по адресу
ror2ru@googlegroups.com
Чтобы отменить подписку на эту группу, отправьте сообщение по адресу: ror2ru-unsubscribe@googlegroups.com
Дополнительные варианты находятся на странице группы http://groups.google.com/group/ror2ru?hl=ru
--
Данное сообщение отправлено Вам, так как Вы являетесь подписчиком группы "RubyOnRails to russian" на группах Google.
FAQ группы находится по адресу: http://ru.wikibooks.org/wiki/RubyFAQ
Для того, чтобы отправить сообщение в эту группу, пошлите его по адресу
ror2ru@googlegroups.com
Чтобы отменить подписку на эту группу, отправьте сообщение по адресу: ror2ru-unsubscribe@googlegroups.com
Дополнительные варианты находятся на странице группы http://groups.google.com/group/ror2ru?hl=ru
Комментариев нет:
Отправить комментарий