lavezzi1: суть в том, что вы никогда не знаете, какой код придется писать через месяц
Стилистически все делается с помощью CSS, то есть, решается добавлением определенного css-класса.
не будет работать в продакшене, т.к. по дефолту скомпилится один файл application.js
Не буду давать ссылку на то, что нужно добавить в конфиг, что бы скомпилить отдельно quizzes, отдельно questions отдельно application - потому что это плохое решение :)
lavezzi1: вопрос сильно ни о чем. для кого правильнее, в каких ситуациях - не понятно
но с другой стороны, логичным кажется, что если у вас в зависимости от роли юзера (гость, админ, пользователь) меняются пункты меню, можно их явно каждый проверять (if current_user.try(:admin?) , if current_user.try(:customer?) и не перерендеривать заново весь блок меню. А если различия в разметке значительные (например, у вас уже идет структура меню не ul -> li, а ul -> .inner -> li -- то можно подумать и о разных лейаутах: для гостя, пользователя, админа.
Сами просто представьте, что если нужно будет для админа рендерить расширенное-мигающее-меню - обернете все в еще один иф?
Все у вас правильно, если, конечно, вы не вырезали чего-то важного из реального кода.
Единственное, что приходит в голову - это то, что код не перезагрузился (сервер, или консоль - работают со старым кодом)
Юрий Молотов: все, в принципе, правильно. Только все же стоит помнить, что когда люди идут на работу - они не идут решать проблемы бизнеса. Они идут решать свои собственные проблемы и задачи. Поэтому нельзя надеяться на то, что появится человек, который сам все разгрузит.
Поэтому, даже специалистам, которые в чем-то намного лучше вас, задачи все равно будете ставить сами. Это просто нужно учитывать, что бы не сказать потом "Мой бизнес прогорел, потому что не справился сотрудник-Х"
ssergy: нельзя стремиться найти золотого человека. таких не бывает. А даже если и найдете - то весь ваш бизнес будет держаться на нем. Точнее, с таким раскладом - это уже не бизнес.
Если работы много (что уже неплохо для начала) - то вам просто нужно правильно построить бизнес-процессы, что б было проще масштабироваться при появлении новых заказов. Например, сведя формулу к линейному 20 проектов \ месяц = 3 новых разработчика и 1 ПМ
Как построить - тут уже все очень индивидуально. Например, разберитесь сначала, почему лично вам приходится тратить много времени и как это оптимизировать. Или почему, работая с 20+ проектов - у вас еще нет пары лексусов (видимо, занимаетесь типичными проектами, а не чем-то серьезным и современным) и т.д. и т.п. Может, нужно будет избавиться от каких-то заказчиков\направлений. Может, сделать работу более конвейерной.
Хорошие книги для начала осознания движения по этому пути: Туалетно-бумажный бизнесмен, Метод тыквы, Фиолетовая корова
Антон Мисягин: В вопросе солр тоже не фигурирует.
Если у вас конкретная проблема - можете выполнить запрос, но не можете его правильно проиндексировать полнотекстовым поисковым движком - то так и пишите. Прикрепляйте схему базы, конфиги движка и ошибки, которые возникают или способы, которые пробовали, но они не дают нужного результата.
Дмитрий Трапов: вот именно "странные требования фреймворков" и помогают вначале осознать объем всех этих штук.
Например, что запрос поступает через миддлвер в диспатчер, дальше на роутер, потом в контроллер и дальше вью-модел и т.д. и т.п. Если будете делать сами облегченный вариант фреймворка для проекта в вакууме - просто о факте наличия диспатчера вообще врядли особо будете задумываться. И у вас могут появиться вопросы, "а не перенести ли роутинг на nginx?"
Дмитрий Трапов: если б взяли, то быстро б перестали велосипедить. Да, такое начало сказалось бы - и, возможно, вам бы казалось, что тот подход, который используется в первом-вашем-в-жизни-фреймворке - единственно-верный. Но это лечится вторым фреймворком с кардинально иной философией
Николай Игнатьев: Главное вовремя остановиться, определишься с ключевыми аспектами и начать реализовывать, что б как можно раньше получить реальную обратную связь и понять, - что важнее дальше
Стилистически все делается с помощью CSS, то есть, решается добавлением определенного css-класса.