Написал недавно движок для синхронизации данных, имеющий первоклассную поддержку оффлайна. Например, можно уйти в оффлайн, изменять данные, закрыть браузер, открыть браузер, открыть сайт (выйти в онлайн) и данные смержатся без потерь. Также во время онлайна данные между клиентом и сервером синхронизируются в реальном времени. Хочу рассказать, в чём была идея, какие есть подобные решения/технологии и кому это может пригодиться.

В этой статье описаны последние события, связанные с Derby. Так же поделюсь мыслями и полезными ссылками.

После двух лет работы над OT (техника разрешения конфликтов при совместном доступе к данным) для Google Wave, Джозефу(Joseph Gentle) пришла в голову идея, что для тех, кто захочет сделать аналогичный продукт, потребуется ни чуть не меньше времени. Чтобы как-то помочь этим людям и поделиться знаниями была написана библиотека ShareJS, представляющая собой реализацию OT на основе NodeJS. Также есть C-реализация.

Будущее будет выглядеть примерно так: везде будет высокоскоростной дешевый беспроводной интернет, операционные системы, в том числе и на мобильных устройствах, будут больше похожи на браузер, вместо программ будут облачные онлайн сервисы, различные устройства от холодильников до очков будут общаться друг с другом через интернет и представлять собой единую программно-аппаратную среду (облачную ОС).

В таком мире пользователи будут платить за пользование онлайн сервисами и, возможно, за устройства. Причем сами по себе устройства без привязки к онлайн сервисам будут иметь небольшую ценность. Онлайн инфраструктура — вот что, на самом деле важно. Уже сейчас в мире существуют тысячи производителей смартфонов, планшетов, ноутбуков и т.п., но использование абсолютного большинства этих устройств связано с использованием ОС, программ или сервисов от всего лишь трёх компаний: Apple, Google, Microsoft.

Тем временем у Derby появился свой хаб.

Ну а сегодня мы поговорим об авторизации и ограничении доступа к данным. Что лучше использовать everyauth или passport? Сложно ли добавить авторизацию? Как ограничивать доступ к данным? Как разделить приложение для пользователей и админку в рамках одного derby-приложения?

Такое громкое название говорит о том, что сегодня мы будет сравнивать концепцию MVC на клиенте (Angular, Ember, Backbone, Marionette, Knockout и т.п. тыщи их) с концепцией Full-Stack (Derby, Meteor). Разберем плюсы, минусы, мифы, заблуждения.

Так получилось, что в последнее время материалов накопилось достаточно и здесь они просто собраны вместе.

Материалы разбиты по группам:
— для сомневающихся
— для начинающих
— для продолжающих

Одни программисты уже осознали открывающиеся перспективы и взялись за изучение Derby. Другие, с интересом наблюдают за происходящим, но не готовы в данный момент расстаться с их любимым фреймворком по разным причинам. Третьи минусуют Derby-туториалы, полагая, что это как-то остановит прогресс и надвигающуюся волну full-stack фреймворков.

Ну а наш паровоз набирает ход и сегодня мы углубимся в наших Derby-изысканиях.

Продолжаем нашу рубрику «ни дня без Дерби». Сегодня мы начнем (наконец-то!) писать код и рассмотрим базовые моменты Derby.js. А так же вы узнаете почему Derby-программисты обычно одиноки, в то время как их более счастливые коллеги, использующие другие фреймворки, работают над аналогичными проектами в веселой дружной команде и с бОльшими сроками.

Если вам не безразличны новые тендеции веб-разработки, то приглашаю поучаствовать в дискуссиях в комментариях к посту Angular vs Meteor vs Derby. Там много интересных мыслей.

Ну а тем временем неделя Derby.js на Хабре продолжается. Популяция Derby-программистов удваивается. И сегодня мы будем учиться бегать на страусах настраивать окружение, создадим приложение, запустим и рассмотрим его структуру.
Если для вас это уже пройденный этап, возможно вам будет интересно посмотреть Tutorial, который по сути Faq. Остальным добро пожаловать под кат.

Надеюсь вы уже прочитали пост про сравнение фреймворков и сделали правильный выбор. Теперь дело за малым — обуздать этого непокорного жеребца, освоить так сказать не паханную целину, ну в общем вы поняли. Предупреждаю, изучение Derby вызывает изменение парадигмы. Мир веб-разработки для вас больше никогда не будет прежним.

После поста о derby.js и перевода сравнения meteor.js и derby.js, главный вопрос, который был в комментариях, звучал примерно так: «Что всё таки лучше derby.js или meteor.js? И зачем вообще всё это нужно, когда можно писать на angular.js + express.js?». Конечно не совсем корректно сравнивать эти фреймворки, так как derby.js и meteor.js — это так называемые full-stack, а angular.js — mvc на клиенте.

Вы веб-разработчик?

Для вас есть новости.

В чем собственно проблема?

Все веб-фреймворки можно разделить на группы. У каждой из этих групп есть свои достоинства и недостатки.

Сервер-ориентированные

Например: RoR, Django, Asp Net, Express.js
Генерируют html на сервере.
Такой подход хорош для статических страничек.
Но как только вы хотите сделать что-то интерактивное, то начинаете утопать в jQuery-коде.

Клиент-ориентированные

Например: Backbone.js, Knockout.js, Ember.js, Batman.js
Генерируют html прямо на клиенте из темплейтов. Код на клиенте структурирован.
Хорошо для интерактивных сайтов.
Не отменяет необходимость использовать сервер-ориентированный фреймворк, что ведет к дублированию кода (модели, валидация и т.д.)

Кросс-компилируемые

Например: GWT, Cappuccino
Позволяют писать всё на одном языке.
Очень большой уровень абстракции.
Шаг вправо, шаг влево — расстрел.

Так же ни один из фреймворков не имеет механизмов синхронизации данных между клиентом и сервером и оставляет реализацию этого на нашу совесть.