Это было интересное чтение, спасибо автору. Уже во многих источниках встречал мысль, что по-настоящему умные люди не стесняются чего-то не знать, не стесняются спрашивать и искать лучшие решения. Возьму этот критерий на вооружение, для отсеивания тех, кто молод-зелен и считает, что знает всё на свете и всё умеет.
1. Это слишком кратко. Многое не написал, т.к. знаю, что тексты хорошо воспринимаются только до определённого количества слов :) Лучше написать продолжение.
2. Я буду с Вами честным: наши рельсы сдались очень многим. А кроме того, на месте Rails в этих примерах мог быть любой фреймворк (хоть и на PHP), приложение на котором реализует CRUD-интерфейс.
Вряд ли у Вас будет на одной странице такое множество РАЗНЫХ моделей, чтобы из их инициализации получилась простыня. Если Вы имеете ввиду, что у вас на странице множество экземпляров одного класса (например, 150 product'ов), то на этот случай Backbone умеет т.н. коллекции. Вы можете обновить сразу всю коллекцию: @products.fetch(). Вот так.
Можно ручками таймер и синкать модель, можно воспользоваться плагинами и сделать обмен в real-time на основе websockets. Вариант с таймером на фоне остальных прелестей бекбона выглядит, конечно, деревянно, но тем не менее внутри обработчика таймера будет всего лишь одна строка: @model_name.fetch() — всё же лучше самописного кода, как мне кажется.
«Нужно» не в смысле «все обязаны так делать». Выгода здесь двойная. Измеримая — в уменьшении трафика, в увеличении скорости обмена с сервисом, уменьшении времени на обработку запросов, уменьшение нагрузки на серверную часть. Выгода другого рода — мы не гоняем туда-сюда информацию, которая не используется в пункте назначения. Если я изменю поле «price» объекта «product», зачем мне слать серверу весь product, там может быть полей на килобайты, описания всякие, массив отзызов, да мало ли что ещё. Хватит отправить price и id и получить в ответ подтверждение, что запрос выполнен.
Попробую ответить. Все атрибуты модели нужно отправлять на сервер только в случае её создания на стороне клиента. Все атрибуты отправлять от сервера клиенту может быть нужно только если логика приложения того требует. Во всех остальных случаях нужно передавать только названия и значения изменённых полей или полей, которые действительно нужны на клиентской стороне в этот момент.
«Поскольку я всё ещё не пишу тесты, я снова комментирую код приложений на Ruby/Rails» :) Без обид.
А я взял и не обиделся. Дело в том, что тесты я пишу, но тесты не могут взять на себя функцию документирования кода, находящегося в процессе эволюции, т.к. тоже постоянно изменяются. Я предлагаю, кроме комментирования «что должен делать код» и «как код должен делать фичу N», взять за привычку документировать процессы, относящиеся к процессу (простите за тавтологию) разработки. А в целом, я согласен, ближе всего к тому, что я хочу реализовать сейчас находится Cucumber с его сценариями.
P.S. Перечитал и понял, что как-то неясно выразился. Постараюсь в будущем развить концепцию своих идей и изложить её яснее :)
Но прошло время, кто-то в процессе рефакторинга или просто прикручивая новую фичу, изменил метод, но забыл поправить комментарий.
Нет, такой сценарий почти нереален, если делается Code Review. Коммит просто будет отправлен на доработку. Само собой, мы предполагаем наличие адекватного review'ера, остальные случаи рассматривать надо совсем отдельно.
Вероятно, Вы правы насчёт «поста о наболевшем», однако, разве не так улучшается мир? Некто пользуется несовершенным инструментом, у него после долгого использования «наболело», он громко заявляет об этом и начинает искать варианты улучшений. И находит. Или другие обращают внимание на проблему и находят.
2. Я буду с Вами честным: наши рельсы сдались очень многим. А кроме того, на месте Rails в этих примерах мог быть любой фреймворк (хоть и на PHP), приложение на котором реализует CRUD-интерфейс.
А я взял и не обиделся. Дело в том, что тесты я пишу, но тесты не могут взять на себя функцию документирования кода, находящегося в процессе эволюции, т.к. тоже постоянно изменяются. Я предлагаю, кроме комментирования «что должен делать код» и «как код должен делать фичу N», взять за привычку документировать процессы, относящиеся к процессу (простите за тавтологию) разработки. А в целом, я согласен, ближе всего к тому, что я хочу реализовать сейчас находится Cucumber с его сценариями.
P.S. Перечитал и понял, что как-то неясно выразился. Постараюсь в будущем развить концепцию своих идей и изложить её яснее :)
Нет, такой сценарий почти нереален, если делается Code Review. Коммит просто будет отправлен на доработку. Само собой, мы предполагаем наличие адекватного review'ера, остальные случаи рассматривать надо совсем отдельно.