Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 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 человек. И тот не особо регулярно, судя по комитам.
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, сделав его немножко лучше и ближе. В том числе и этими статьями.
Дерби не пытается занять место целой экосистемы с деплоем, облаком приложений, своей системой модулей, репозиторием и т.д. И это просто офигенно. Именно это мне и нравится в дерби. Мне нужно запускать задачи по расписанию — я использую 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, сделав его немножко лучше и ближе. В том числе и этими статьями.
Допустим я хочу при добавлении туду мониторить дату когда это туду было добавлено.
Например:
Вот это вот +(new Date) должно сработать на сервере, а не прийти от клиента.
Как видно из дерби-примеров chat.derbyjs.com/lobby пытливые товарищи быстро добрались до этой даты и зафигачили на сервер свою.
Как сделать изоляцию клинта от сервера?..
Например:
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(), но там как с моделями и параметрами передаваемыми?
Ну например вот камменты тут будут лайв, по мере того как их пишут, в нагруженном проекте это допустим будет 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'))
}
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Изучаем Derby 0.6, пример #2