Видимо придирка к «распределение… описывается», я бы сказал «данные распределены вдоль прямой», но я ни разу не переводчик. Ну и в целом «алгоритмы данных предполагают» звучит довольно необычно :-)
Но как быть простому смертному? Простому, нормальному парню, который в гробу видал все эти технологии. Парню, который не торчит от новой операционки, или сраного гаджета.
Как вариант — смириться с недостатком мозгов и найти менее требовательную профессию. В депутаты можно пойти, ограничительные законы писать. Заодно можно с легкостью отыграться на этих мерзких «ботанах».
Размазывать сопли о прокуренную жилетку хабра — не вариант. А то так и будет — «жизнь заставила быть программистом», а хочется «тискать девочек во дворах» и прочее нытье. Следуйте моде: nodejs, mongodb — читать много не надо и девочкам в клубах будет что рассказать.
Как правило, такие туториалы предназначаются для самого начального уровня, чтобы можно было быстро вовлечь человека. Рассматривать здесь вопросы настройки продакшена совершенно не к месту. К тому же из начала статьи понятно, что текст от новичка к совсем новичку.
Про respond_to никто не забывает. Полезная штука. Но, к сожалению, тоже не универсальная.
Презентеры — это уже немного про другое, в любом случае, возникает вопрос о том, как хранить эти самые презентеры, чтобы удержать контроль над кодом.
Раз уж заговорили про презентеры, то вот — blog.carbonfive.com/2012/01/10/does-my-rails-app-need-a-service-layer/
Rails way, Rails wayем, а то что реально решает проблемы, пропускать не стоит.
А разгадка одна — желание сделать код как можно более легким для поддержания. CanCan — норм, когда речь идет о простых вещах. Сложные контроллеры порождают кучу условных фильтров, мусорных спецификаций (типа блоков respond_to) и соотношение неполезного кода к полезному становится не в пользу последнего. Некоторых людей это раздражает.
Использовать такое разделение с самого начала проекта, конечно, спорное решение. Особенно, когда непонятно, появятся такие сущности или нет. Но, например, автор статьи несколько месяцев назад подал идею разнести отдачу html и js по разным контроллерам. А именно, js-ответы вынести в API. Совсем не типично для Rails Way, но результат на практике мне очень нравится.
А в целом — присоединяюсь к комментатору ниже, написавшему про Engines. Особенно с Rails 3.1+
Да, да. Аджайл — это дисциплина (а, RUP видимо — вершина безалаберностью). Всегда казалось, что аджайл — это гибкость, свобода. Жертвуем строгостью процесса, ради более эффективной работы. Individuals and interactions over processes and tools и все такое.
Но, проповедники налегают. В общем, комментарии выше вскрывают проблемы в полной мере, почти нечего добавить.
Развернутый ответ на этот вопрос заслуживает отдельного топика. Почему-то его задают чаще всего (вместе с «а что будете делать, если на вас наедут?» :-)
Если кратко, будем бороться комплексно: продуманное управление репутацией пользователя, ручной модерацией, будем давать слово бизнесу и будем учить его работать с такими отзывами.
К сожалению, это не самая тяжелая задача, которую нам предстоит решить.
Тогда надо работать над тем, чтобы поход к руководителю не был неприятной, стрессовой ситуацией. Уходить от «жалоб» и «попрощайничества» к чему-то более конструктивному.
Разработчики достаточно профессиональны и хорошо мотивированы
Есть доверие между заказчиком и исполнителем (или это работа над собственным продуктом)
тогда описанный подход может дать хороший результат с минимумом затрат на побочную деятельность.
В комментариях часто прослеживаются вопросы — «а если разработчики то..., а если это...». Да, если разработчики не опытны, не понимают что и зачем они делают или не хотят сами это сделать — то да, нужно пасти. В другом случае — достаточно периодически корректировать и не мешать.
У меня в команде отсутствуют явные итерации и оценки (типа Kanban); могу сказать, что без них очень даже неплохо. Да, сложно прогнозировать дату очередного релиза, но точности от нас не требуют. Процесс простой — сначала максимальный scope down нового функционала + багфиксинг и менее приоритетные задачи. Если после этого остается какое-то время (т.е. не релиз может ждать) — то добавляем выкинутые фичи (сколько влезет) и релизим. А можем сразу зарелизить и перенести остатки в следующий релиз.
Без практики никуда. Для меня очень хорошей книгой оказалось thepowerofless.com/ Прочитал только одну пятую книги пару месяцев назад и пока даже нет желания дочитывать — информации для практики хватает.
Еще одно доказательство, что хорошие идеи возникают одновременно :-) Разработка sonru.com также велась в 2008 (или даже раньше, уже забыл). И приложение изначально рассчитано на европейскую аудиторию.
Идея отличная, и, насколько я знаю, там она работает. Так что вам удачи и спасибо за продукт!
В любом случае спасибо за труд!
Как вариант — смириться с недостатком мозгов и найти менее требовательную профессию. В депутаты можно пойти, ограничительные законы писать. Заодно можно с легкостью отыграться на этих мерзких «ботанах».
Размазывать сопли о прокуренную жилетку хабра — не вариант. А то так и будет — «жизнь заставила быть программистом», а хочется «тискать девочек во дворах» и прочее нытье. Следуйте моде: nodejs, mongodb — читать много не надо и девочкам в клубах будет что рассказать.
P.S. Заранее прощу прощения за убитое время.
Презентеры — это уже немного про другое, в любом случае, возникает вопрос о том, как хранить эти самые презентеры, чтобы удержать контроль над кодом.
Раз уж заговорили про презентеры, то вот — blog.carbonfive.com/2012/01/10/does-my-rails-app-need-a-service-layer/
Rails way, Rails wayем, а то что реально решает проблемы, пропускать не стоит.
Использовать такое разделение с самого начала проекта, конечно, спорное решение. Особенно, когда непонятно, появятся такие сущности или нет. Но, например, автор статьи несколько месяцев назад подал идею разнести отдачу html и js по разным контроллерам. А именно, js-ответы вынести в API. Совсем не типично для Rails Way, но результат на практике мне очень нравится.
А в целом — присоединяюсь к комментатору ниже, написавшему про Engines. Особенно с Rails 3.1+
Но, проповедники налегают. В общем, комментарии выше вскрывают проблемы в полной мере, почти нечего добавить.
Если кратко, будем бороться комплексно: продуманное управление репутацией пользователя, ручной модерацией, будем давать слово бизнесу и будем учить его работать с такими отзывами.
К сожалению, это не самая тяжелая задача, которую нам предстоит решить.
- Разработчики достаточно профессиональны и хорошо мотивированы
- Есть доверие между заказчиком и исполнителем (или это работа над собственным продуктом)
тогда описанный подход может дать хороший результат с минимумом затрат на побочную деятельность.В комментариях часто прослеживаются вопросы — «а если разработчики то..., а если это...». Да, если разработчики не опытны, не понимают что и зачем они делают или не хотят сами это сделать — то да, нужно пасти. В другом случае — достаточно периодически корректировать и не мешать.
Идея отличная, и, насколько я знаю, там она работает. Так что вам удачи и спасибо за продукт!