Комментарии 7
Дреби интересен как концепция. Довольно много интересных вещей сделано правильно. Но (со стороны) ему еще очень далеко до production. Не хватает самых банальных и скучных вещей (в скобка ссылки на некоторые rails-библиотеки):
1) Пример регистрации/логина/ограниченного изменения ресурсов. До livedb 0.4 вообще не было возможности работать с отдельными полями. Как теперь — может и есть, нужно изучать что именно там добавили.
2) Деплой. По типу cap production deploy
3) Миграции БД вперед и назад.
4) Что там с тестами.
5) Настройка Ubuntu LTS с нуля на эту штуку.
6) Мониторинг производительности.
7) Какие там логи и как их можно анализировать (gem 'request-log-analyzer')
8) Как в режиме разработки фреймворк реагирует на 500ую серверную ошибку. gem 'better_errors'
9) Как идет работа с отправкой почты и ее отладкой
10) Как вообще с фоновыми задачами обстоят дела (gem 'sidekiq')
11) Какие-нибудь бест-практики, хоть немного
12) Как документировать АПИ, БД и другое
13) Какие-то аналоги asset pipeline (объединение и преобразование js, css, png)
14) Шаблон проекта с бутстрапом
15) Поддерживаются ли HAML, SASL, Coffescript или аналоги
16) Интеграция с cron-задачами (gem 'whenever')
17) Как разработчик оповещается об ошибках в продакшене (gem 'exception_notification')
18) Как задаются настройки приложения (в каких-нибудь yaml-файлах)
19) Как делаются переводы приложения (хотя бы ru/en как минимум)
и т.п.

Этих материалов не видел и на англ. языке.

Когда эти вещи будут задокументированы (а в большинстве случаев еще и написаны/портированы), тогда можно будет говорить о Derby как фреймфорке для production. Сейчас же ИМХО только там где без него получается намного тяжелее, т.е. мало где.

Во всём этом пугает то, что фреймворком занимается только 1 человек. И тот не особо регулярно, судя по комитам.
Большинство ваших пунктов снимается, если четко определить место дерби в экосистеме. Итак, дерби — это npm-модуль, которым расширяется обычное node-овское expressjs-приложение. Отсюда, например, ответим на пункт пятый: «Как с нуля настроить Ubuntu под дерби?» — да абсолютно так же, как под обычное expressjs приложение, использующее mongodb и redis. Вообще нет отличий.

Дерби не пытается занять место целой экосистемы с деплоем, облаком приложений, своей системой модулей, репозиторием и т.д. И это просто офигенно. Именно это мне и нравится в дерби. Мне нужно запускать задачи по расписанию — я использую npm-модуль «cron» (он мне понравился больше других), нужно рассылать почту, беру node-mailer, хочу предварительно сжимать картинки/что-то делать с css и т.д — у меня есть grunt, gulp и т.д. Понимаете? Такая архитектура позволяет мне использовать все, что есть в nodejs экосистеме.

И недостатки здесь те же, что и вообще у ноды. Ну нет еще нормального модуля для деплоя под ноду. Мы сами в своих проектах для этого используем capistrano… Да — это так.

Так, пробегусть по пунктам, ответы на которые знаю:

CoffeeScript поддерживается из коробки, есть jade — альтернативный шаблонизатор вметсто handlebars (мы думали сначала о haml-е, но jade нам лично показался удобней, в итоге derby-jade). Для конфигов, мы лично исопjльзуем grunt-yaml, а потом nconf. Третий бутстрап добавляется одной строкой — из коробки есть less, но вы правы, я, например, не знаю о scaffolding-tool, которая бы в пару комманд развернула бы derby-приложение с предустановленным less-бутстрапом (по-моему в yeoman-е еще нет derby).

Бест-практики, как и документация в паблике — вы правы, отсутствуют. Мы у себя нарабатываем, созреем — поделимся. Ничего не могу сказать про миграции — просто не знаю, есть ли какие-то вообще инструменты на эту тему у монги (хотя вроде заканчивал курсы mongodb university по разработке, и там не было ничего такого), переводами тоже не занимался — не могу сказать.

Вообще, понятное дело. Кучу всего еще надо сделать, но для меня лично делема решена. Каждый, наверное, задает себе вопрос: а стоит ли то, чем я занимаюсь вложенных усилий. И мой ответ — да. Технология офигенна, и, вместо того, чтобы использовать вовсю нафаршированные технологии вчерашнего для, я лучше внесу свою лепту в derby, сделав его немножко лучше и ближе. В том числе и этими статьями.
Допустим я хочу при добавлении туду мониторить дату когда это туду было добавлено.

Например:

this.model.add('todos', {
    text: newTodo,
    completed: false,
    ctime: +(new Date)
  });



Вот это вот +(new Date) должно сработать на сервере, а не прийти от клиента.

Как видно из дерби-примеров chat.derbyjs.com/lobby пытливые товарищи быстро добрались до этой даты и зафигачили на сервер свою.

Как сделать изоляцию клинта от сервера?..
На ваш вопрос по указанию времени я отвечу так — мы сами у себя используем фукнционал так называемых хуков racer-а, кто-то из создателей дерби выкладывал когда-то gist c кодом — его мы и используем в своих проектах. Специально ради ответа на ваш вопрос (хотя в принципе — давно пора), я вынес этот функционал и оформил в модуль derby-hook. В близжайшее время постараюсь сделать к нему нормальную документацию с примерами. В вашем случае будет так (нужно вносить изменения в файл server.js — см. урок #3)

  var derbyHook = require('derby-hook');
  // В store добавляем функцию hook
  derbyHook(store);
  
  store.hook('create', 'todos', function(docId, value, session, backend) {
    model = store.createModel();
    model.fetch ('todos.'+docId, function(err){
      var time = +new Date();
      model.set('todos.'+docId+'.ctime', time);
    })
  });

В «дерби-приложении», соответственно, ничего в ctime не пишите.
Еще сразу вопрос в догонку, можно как-то функционал реактивный отключать или эээ делать так чтоб обновления страницы были по тыку кнопки?

Ну например вот камменты тут будут лайв, по мере того как их пишут, в нагруженном проекте это допустим будет 1 каммент в секунду, страница будет плясать и прыгать.

ТЗ: оставить кнопку которую пользователь сам нажмет (или событие, допустим скролл к началу или к концу страницы когда пользователь прекратил читать) и можно обновить страницу.

Подозреваю что нажатием этой кнопки должно быть что-то типа page.render(), но там как с моделями и параметрами передаваемыми?
Для того, чтобы отключить реактивное обновление при выводе можно сделать, например, так {{unbind _page.value}}, либо, как в вашем случае, можно сделать необновляемым целый блок:

{{unbind}}
  <!-- ваш html с нереактивными {{_page.values}} вставками -->
{{/}}

А для того, чтобы в определенный момент все это перерисовать нужно использовать ключевое слово on, то есть у вас будет примерно так:

{{on _page.trigger}}
  {{unbind}}
    <!-- вывод комментов -->
  {{/}}
{{/}}
<a href="#" on-click="refreshTodos()">Refresh</a>

А при нажатии на кнопку что-то типа:

app.proto.refreshTodos = function(){
  app.model.set('_page.trigger', !app.model.get('_page.trigger'))
}
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.