Как стать автором
Обновить

Комментарии 10

Здравствуйте.

Скажите пожалуйста, а зачем разработчику ставить этот гем и писать
translate_action(:edit)

вместо того, чтобы сделать так:
t('actions.edit')

или вообще создать свой хелпер или расширить i18n?

Просто это выглядит как набор никак не связанных друг с другом небольших решений, принятых в Вашей команде разработчиков, но объединённых в гем для удобства этой же команды.
Здравствуйте!

Компоненты действительно не связаны друг с другом. Почему они оказались вместе, я упомянул в начале поста. При этом в RailsStuff собраны, конечно, не все модули, которые мы когда-либо использовали. Только те, которые мы использовали во многих проектах, которые часто добавлялись в первых комитах. Чтобы не копить дубликаты файлов, вынесли их все в гем.

Относительно хэлпера перевода, я вижу несколько плюсов:
— Скорость работы вкупе с удобством использования. Для многих производительность в приложениях на рельсах — спорный вопрос, а жаль. Если это не аргумент, просто пропустите, пожалуйста. I18n.t — довольно сложный вызов и не самый быстрый. Время работы его растет, если используются фолбэки. Хранить перевод в локальных переменных, чтобы не переводить в циклах одно и то же — эффективнее, конечно, но больше писать надо, да и не все хотят.
— Один общий вариант использования. Не надо вспоминать, как надо переводить, нет длинных ключей, в которых можно ошибиться.
— Один общий способ организации переводов. Нет выбора, куда бы ещё положить перевод. Позволяет избежать повторений.

Свой хэлпер — это тоже хорошо. Просто тут он уже готовый. Только патчить I18n для этого не надо, имо :)
Ну с вами всё понятно.
Начинание неплохое, но по-факту сборная солянка. У нас нечто подобное по гистам на гитхабе раскидано. Нет, безусловно есть неплохие удобные вещи, но я соглашусь с первым комментатором что это разнобой. В качестве статьи на хабре — интересно посмотреть как что использует ваша команда, но в реальной жизни и проектах использовать все же мало кто будет.

P.S. вы бы идею ResourceController развили в отдельный гем. Я думаю это было бы значительно полезнее для сообщества, тем более в качестве альтернативы полумертвого InheritedResources. А остальное не нужно, имхо.
Попробую на статью набрать чего-нибудь интересного. Но сейчас всё кажется очень банальным.

Если ResourcesController будет быстро развиваться или окажется, что его лучше вынести отдельно — так и сделаем. То же самое и про все остальные части. Пока что, по-моему, это было бы не рационально — несколько гемов поддерживать требует больше времени, чем один. Гисты сложнее поддерживать в актуальном состоянии, и тесты к ним писать.

Скажите, что вас останавливало бы от использования одного только ResourcesController, установив весь набор? Все сделано на autoload, остальные файлы даже прочитаны не будут.
Узкопрофильные гемы как правило стабильнее, они лучше развиваются и у них значительно меньше мусора. Текущий подход приведет к тому что придется следить по change-логу о тех изменениях которые не нужны, а это информационный шум, да и понимание концепции развития тоже немаловажно — пока это некоторый toolbox отдельно взятой команды, в нем завтра может появиться еще mp3-плеер и генератор QR-кодов, а также хэлперы со ссылками на амиго или еще что, и даже если это все будет на автолоаде, тащить гору мусора тоже не хочется. По предпочтениям, я даже стараюсь ставить гемы с --no-ri --no-rdoc дабы не тащить лишнего.
Про ченджлог согласен. Но зачем так про амиго сразу :) Выше я писал:

При этом в RailsStuff собраны, конечно, не все модули, которые мы когда-либо использовали. Только те, которые мы использовали во многих проектах, которые часто добавлялись в первых комитах.

Всё, что вы перечислили, не вписывается в имеющийся набор, т.к. очень специализированное.

> тащить гору мусора тоже не хочется

Какие объективные причины для такой точки зрения? Я уверен, что и в рельсах и во многих других гемах мало кто использует абсолютно все функции/файлы, которые едут в геме.
Степень специализированности определяется той же командой которая использует этот тулсет. То есть если например завтра вы будете во всех проектах использовать feature_X, то велика вероятность что в тулсете это появится вне зависимости от того, нужно это или нет остальному сообществу. Подозреваю что в перспективе это может разрастись еще больше. Нет, я ни в коем случае не против такого подхода. Я просто говорю что наработки конкретной команды в их сыром виде не всегда удобно использовать остальному миру.

Что касается объективных причин такой точки зрения — её нет, чистый субъективизм. Но программисты — народ капризный и весьма принципиальный. Я частенько вычищаю из проектов лишние не используемые гемы и код. Иначе какое-то чувство дискомфорта остается. Это как спать с горой грязной посуды в раковине — кому-то всё равно, а кого-то это раздражает и он не может спокойно уснуть просто зная что всё не на своих местах. По этой же причине если мне нужно пройти 100 метров, я иду пешком а не вызываю такси. Возможно исходя из подобных суъбективных предубеждений, я не буду ставить большой мультифункциональный гем если мне из него нужен один единственный хэлпер.
Не имею ничего против предоставленных инструментов. Некоторые из них действительно занятны.

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

Именно поэтому лучше не дампить в гем всё что тянется из проекта в проект, а выделить некоторые действительно полезные компоненты, подумать о нестандартных сценариях, улучшить их и добавить кастомизацию (если нужно) и только потом сделать гем. Но на это, конечно, нужно намного больше дополнительного времени.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий