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

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

Окружение

Будем считать, что у вас Linux семейства Debian (Ubuntu, Debian и т.п.). Настройка окружения для других ОС: другие Linux, Windows, Mac OS имеет свои особенности, но принципиально не отличается.
Для того, чтобы запустить Derby приложение, нам нужно: node.js, mongodb, redis.

Для node.js и redis, мы будет использовать репозитарий chris-lea, у mongo есть официальный.

# Добавляем репозитарии # node.js sudo add-apt-repository -y ppa:chris-lea/node.js # mongodb sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 7F0CEB10 sudo echo 'deb http://downloads-distro.mongodb.org/repo/ubuntu-upstart dist 10gen' | sudo tee /etc/apt/sources.list.d/10gen.list # redis sudo add-apt-repository -y ppa:chris-lea/redis-server  # Обновляем apt-get sudo apt-get -y update  # Устанавливаем sudo apt-get -y install nodejs sudo apt-get -y install mongodb-10gen sudo apt-get -y install redis-server 

Приложение

Мы конечно можем сейчас запилить приложение с нуля. Что нам стоит дом построить?
Но в Derby есть утилита, которая генерирует для нас макет приложения и экономит время. Почему бы нам не воспользоваться этим?
Для этого нам нужно установить npm пакет derby глобально:

npm install -g derby 

Создаем приложение, с названием hello-derby (это будет также название папки):

derby new hello-derby 

Утилита создаст нам приложение и установит все зависимости. Это займет какое-то время и в конце вы увидете:

  Project created!    Try it out:     $ cd hello-derby     $ npm start    More info at: http://derbyjs.com/ 

Мы будем рассматривать js приложение, но если хотите Coffeescript, используйте —coffee, -c:

derby new --coffee my-cool-coffee-derby-app 

Также можно создать пустое приложение (только макет):

derby bare my-bare-app 

Или создать приложение, но не устанавливать зависимости при помощи —noinstall, -n:

derby new -n empty-node_modules-app 

Запускаем

Чтобы запустить, как вы уже догадались, нужно:

cd hello-derby npm start 

Видим:

1234 listening. Go to: http://localhost:3000/ 

Теперь в браузере идем сюда: http://localhost:3000/
Ура, работает!

Структура

Давайте быстренько пробежим по структуре проекта.

/lib — тут почти весь js. Если вы на coffee, то будет папка /src.
/lib/app — это то, клиентское приложение с названием app. Таких приложений может быть несколько. В общем это то, что может выполняться на сервере и также загрузится на клиент.
/lib/app/index.js — тут создается само приложение, добавляются компоненты ‘derby-ui-boot'(это bootstap для derby) и ‘ui'(это пользовательские компоненты). Затем создаются routes, которые будут исполняться и на сервере и на клиенте. В конце создаются контроллеры — это функции, которые исполняются только на клиенте и связанны с манипуляциями dom.
/lib/server — это серверное приложение. Может быть только одно. Тут код, который выполняется только на сервере и с клиента напрямую не доступен.
/lib/server/error.js — здесь мы генерируем пользовательские статичные странички ошибок (без клиентского приложения).
/lib/server/index.js — здесь создается express.js приложение, настраиваются базы данных, создается store, добавляем в express app модули connect, некоторые их которых являются частями Derby приложения. В конце создается server-side route, который выдает ошибку если до этого не сработал ни один route.
/node_modules — тут npm пакеты.
/styles — тут стили. По умолчанию Stylys. Могут быть разными для разных клиентских приложение (по именам папок). В ui — стили компонентов.
/ui — тут компоненты. Каждый компонент состоит из js и html файлов и находится в папке со своим имененм.
/ui/connectionAlert — это пример компонента. Если клиент ушел в оффлайн, этот компоненты выводит соответсвующую надпись и кнопку «Reconnect». Если переподключиться не удалось, он предлагает перезапустить приложение «Reload».
/ui/index.js — тут общие настройки компонент.
/views — html темлейты.
/views/app — тут те темплейты, которые загрузятся в клиентское приложение app.
/views/app/home.html — это стартовая страница.
/views/app/index.html — это layout для home.html и list.html.
/views/app/list.html — лист.
/views/error — тут лежат темплейты для ошибок, которые мы загружаем из /lib/server/error.js
.npmignore — это вам нужно будет если вы свое приложение будете публиковать в npm как пакет.
Procfile — это для Heroku
README.md — прочитай меня
package.json — это настройки для npm. Тут указаны все ваши зависимости. А так же что делать, если вы набрали npm start.
server.js — самый главный файл. Точка входа вашего приложения. Тут Derby запускает express приложение.

25 сентября в дата-центре NORD 3 прошел семинар по катастрофоустойчивому облаку CloudLine Metrocluster.

Семинар по новой услуге открыл генеральный директор, Юрий Самойлов, кратко рассказавший об основных вехах компании, нашей сети дата-центров и, конечно же, об облачных услугах DataLine.

Технический директор Сергей Мищук провел своеобразный экскурс в «облачную» историю DataLine, отметив основные этапы эволюции облака CloudLine:

В 2010 году компания начала использовать решение Double Take для асинхронной репликации файловой системы (на базе дата-центров OST и NORD), однако это решение имело достаточно высокую стоимость.
В 2011 уже на базе VMware DataLine запускает облако CloudLine. Тогда же, с учетом спроса заказчиков на катастрофоустойчивое решение, были проведены испытания системы VMware Site Recovery Manager (SRM).
Развитие сетевой инфраструктуры между двумя площадками OST и NORD на протяжении 2012-2013 гг., а также переход на СХД NetApp позволили в текущем году предложить привлекательное по цене катастрофоустойчивое облачное решение. Одним из главных отличий нового решения стала синхронная репликация на уровне СХД, которая дает возможным держать в активном состоянии обе площадки (при использовании решения SRM одна из площадок оставалась пассивной).

Эдуард Бавижев, руководитель группы виртуализации, в своей презентации рассказал об архитектуре CloudLine Metrocluster и описал различные сценарии отказов:

В основе СloudLine Metrocluster дублирование элементов СХД в рамках двух площадок — дата-центр OST и NORD, расстояние — 33 км. Решение работает на СХД NetApp и VMware vSphere.
Благодаря синхронной репликации данных на уровне СХД, при таких сбоях, как нарушении каналов связи СХД между ЦОД или отказе контроллера СХД в одном из ЦОД, системы продолжат работать без перерыва. В случае отказа физических серверов на одной из площадок восстановление виртуальной среды занимает от 2 минут (это время на запуск операционной системы и виртуальных машин).
Наконец, при полном отказе одного из ЦОД на восстановление системы на другой площадке уйдет до 15 минут.

После сессии вопросов и ответов, гости дата-центра отправились на экскурсию по новому дата-центру NORD 3. Кроме основных инфраструктурных систем, посетители смогли оценить и оформление ЦОДа, которое было закончено совсем недавно.

А из нашего окна стройка нового ЦОДа видна 🙂

Интенсивное развитие облачных сервисов не оставляет равнодушным. Нашe внимание остановилось на сервисе Amazon — Elasctic Cloud Compute. Возникла задача развернуть проект node.js использующий Derby. Amazon Elastic Beanstalk так же поддерживает node.js, однако мы ограничимся только сервисом Amazon EC2. Кроме того «из коробки» Amazon Elastic Beanstalk предлагают Amazon Linux с предуставновленным node.js + nginx. В нашем случае Amazon Linux не подходит, версия node.js и связка node.js+nginx также.,

Создание инстанса и коннект к EC2 серверу

Предполагается, что вы зарегистрированы в AWS, и имеете доступ в AWS Managment Console.
Запускаем EC2 Instance:

1. Заходим в AWS Managment Console
2. Выбираем регион (в нашем случае US East (N.Virginia) )
3. Переходим Services -> Compute & Nerworking -> EC2
4. Launch Instance: Выбираем Ubuntu Server 13.04 x64, настраиваем ключи, и другие необходимые параметры, в т.ч. Instance Type (в нашем случае t1.micro)
5. После создание в списке инстансов наблюдаем как наш сервер получит state running
6. Соединяемся с сервером по ssh: для этого в списке инстансов нажимаем правой кнопкой на нужном, выбираем Connect -> Connect with a standalone SSH Client
   Будет что-то типа:
   

   $ ssh -i yourkey.pem ubuntu@ec2-184-119-234-139.us-east-1.compute.amazonaws.com 

7. Коннектимся к серверу по параметрам полученым в пункте 6.

Мы будем использовать такую связку: node.js+derby+redis+mongodb
Последовательно установим нужные пакеты.

Устанавливаем Node.js.

Для Derby.js будем использовать версию node.js 0.10.17

1. Качаем исходники:
   

   $ wget http://nodejs.org/dist/v0.10.17/node-v0.10.17.tar.gz 

2. Распаковываем:
   

   $ tar -xvf node-v0.10.17.tar.gz $ cd  node-v0.10.17 

3. Устанавливаем:
   

   	$ sudo apt-get -y install checkinstall 	$ checkinstall -D --install=no --nodoc --pkgversion=0.10.17 --pkgname="Node.js 0.10.17" 	$ sudo dpkg -i node*.deb 	

4. Устанавливаем DerbyJS:
   

   $ sudo npm install -g derby 

Устанавливаем Redis 2.6.16

1. Скачиваем:
   

   $ wget http://download.redis.io/releases/redis-2.6.16.tar.gz 

2. Распаковываем:

   $ tar -xvf redis-2.6.16.tar.gz $ cd redis-2.6.16 

3. Устанавливаем:
   

   $ sudo checkinstall -D --install=no --nodoc --pkgversion=2.6.16 --pkgname="Redis 2.6.16" $ sudo dpkg -i redis*.deb 

4. Настраиваем
   

   $ sudo mkdir /etc/redis $ sudo mkdir /var/redis $ sudo cp utils/redis_init_script /etc/init.d/redis $ sudo cp redis.conf /etc/redis/6379.conf $ sudo vi /etc/redis/6379.conf 

   указываем параметры

   daemonize yes logfile /var/log/redis.log dir /var/redis/ 

   сохраняем файл

5. Запускаем сервис:
   

   $ sudo service redis start 

6. Добавляем в автозагрузку:
   

   $ sudo update-rc.d redis defaults 

7. Проверяем:
   

   $ redis-cli redis 127.0.0.1:6379> ping PONG redis 127.0.0.1:6379> exit 

Устанавливаем MongoDB

1. Установка:

   sudo apt-get -y install mongodb 

2. Проверяем статус:
   

   $ service mongodb status 

   Пример ответа:
   mongodb start/running, process 24815

Создаем приложение Derby

1. Создание

   $ mkdir ~/www $ cd ~/www $ derby new myapp $ cd myapp 

2. Проверяем запуск:
   

   $ nmp start 

Запускаем как демон

Пожалуй один из простых способов:

$ cd ~/www/myapp $ nohup node server.js & 

Также можно воспользоваться supervisord или другой тулзой.

Ссылки / источники

• nodejs.org/
• derbyjs.com/#create_an_app
• stackoverflow.com/questions/4018154/node-js-as-a-background-service
• redis.io/topics/quickstart
• supervisord.org/
• docs.aws.amazon.com/elasticbeanstalk/latest/dg/Welcome.html

Привет, Хабр.

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

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

Статические

Пока способов сделать веб удобным для дальтоников довольно мало, но, в принципе, существующие довольно просто осуществляются. Итак, из статических способов можно выделить три:

1. Замена цвета до монитора
2. Замена цвета при помощи клиента
3. Цветовая статика на сайте

Замена до монитора

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

Замена цвета при помощи клиента

Практически идеальный вариант. Возможно, некоторые из читающих знают стили форумов и сайтов, в которых можно менять расцветку. В некоторых используют куки-файлы, но это только для предустановок. Но вот незадача — зелёный, синий цвета я различаю, а красный с жёлтым — нет. Слепой на красный цвет вряд ли различит зелёный и красный соответственно. Увы, способ предустановок тоже не подходит, т.к. практически всегда в таком способе имеются цвета, на которых идёт совпадение оттенков или вообще полное совпадение цветов. Но об этом методе поговорим чуть ниже.
Некоторое время назад я стал играть в BF3. И, о да, это адово. Просто потому что разработчики не учли, что красный, зелёный и синий — решение для дальтоников. Я рылся и пытался сделать что-то вроде WH (wallhack), но лишь меняющего цвет, выводимый на экран. К сожалению, метод уж очень сложным был и его пришлось бросить, однако он мог бы стать довольно функциональным.
Касательно же замены цветов в браузере — в данный момент лучшим способом будет именно подмена CSS на свой. Проще говоря, радужный дизайн 1337 сайта станет не только унылым, но и довольно противно выглядящим. Однако будет более функционален, нежели неразличимый оригинал. Возможно, будет интересен способ попытаться организовать ту же «потоковую» замену при помощи плагинов для браузера (увы, на это не хватает знаний).

Цветовая статика на сайте

В общем-то интересный способ. Может быть, кто-то видел сайт www.roi.ru (переключатель в хидере [1]). Здесь вся задача лежит именно на дизайнере (если цветовая гамма предлагается одна, но основная и удобная для большинства типов дальтонии), либо на программисте кода, который поможет настроить сайт посетителю под себя. Так, я «избрал» и «доделал» дизайн для форума, однако он может стать несколько неудобным для других типов дальтоников:

И моё восприятие без коррекции:

К сожалению, дизайнерам непросто понять, как именно видят те же «основные» типы дальтоников, а потому такой метод работает не всегда и лишь на специализированных сайтах. Обычно тематические порталы (игровые, например) не заботятся об этом и доставляют тем некоторые неудобства читателям (откройте сайт той же Игромании и фильтрами замените цвета на выбор, вы увидите, что часть цветов или ссылок слились и невидимы или неразличимы).

В результате можно организовать наиболее удобный и простой метод осуществления коррекции — на стороне клиента. Увы, для этого требуется работа создателя сайта над третьим пунктом, так что полностью разделить два этих способа у меня пока не вышло. Даже с коррекцией через PS я, создавая дизайн, не могу определить точно, будет ли работать он так же «них», как для меня.

Динамический метод

В принципе, описанных выше способов могло бы быть предостаточно для почти полной компенсации недостатков зрения. Но вот беда, подо всех слепых на цвета подстроиться не получится. Ну никак.
Я написал выше, что обсудим один из методов. Ну что, вот как это в расширенном смысле будет выглядеть.
Предустановки создателя продукта/сайта зачастую являются бесполезными для тех кто является дальтоником по «нестандартному» (не крс./зел.) типу. Так, уже затронутый выше BF3 даже со включенным режимом цветовой слепоты мало что может дать — контрастность да замену пары цветов, не являющихся основными. Приходится искать обходные пути для решения проблемы — «читерский» (замена цвета при помощи драйвера (фильтр-экран)).
Некоторое время я практиковал использование палитр для кастомизации стиля сайта, но из-за нецелевого использования сайт по внешнему виду напоминал Упячку в приступе эпилепсии, потому и пришлось отказаться от использования такого метода.

Может быть у кого-то есть опыт работы в такой сфере? Какие-нибудь варианты решения кроме этих есть?

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

В эксперименте участвуют браузеры Chrome 23, Firefox 16, IE9. Пинг до сервера ~41ms, на сервере включен gzip, условия максимально приближены к боевым. Итак, что будем мереть/смотреть? Создадим тестовую страницу с подключенными к ней таблицами стилей. Тестовая страница представляет собой необходимый минимум (Doctype, html, head и body )Подключая стили разного размера будем замерять время загрузки страницы и время загрузки отдельного файла. На основе полученых данных сделаем выводы о том до каких пор файлы стоит склеивать.

Тест №1.
Размер одного файла — 2.1Kb
Gzipped(including http headers) — 451b
Количество подключенных файлов — 10

Chrome

onload = 208ms
connecting+waiting = ~83ms
receiving = ~2ms

FF

onload — 291ms
connecting+waiting = ~88ms
receiving = ~1ms

IE

onload — 417ms
connecting+waiting = ~190ms
receiving = <1ms

Chrome и FF показали почти одинаковый результат, время ожидания ответа приблизительно равно двойному ping (посылаем запрос — получаем ответ), а вот IE странно распаралелил запросы, из-за чего часть их них была вынуждена ждать окончания предыдущих. Время передачи данных намного меньше времени создания соеденения/ожидания ответа. В данном случае смысл склеивать файлы есть.

Склеиваем файлы, размер — 208Kb(1.14Kb gzipped), браузеры грузят страницу с такой скоростью:
Chrome — 142ms(-42%), FF — 165ms(-44%), IE — 389ms(-7%)

Тест №2.
Размер одного файла — 20.7Kb
Gzipped(including http headers) — 523b
Количество подключенных файлов — 10

Chrome

onload = 284ms
connecting+waiting = ~110ms
receiving = ~1ms

FF

onload — 352ms
connecting+waiting = ~90-130ms
receiving = ~1ms

IE

onload — 830ms
connecting+waiting = ~190ms
receiving = <1ms

Склеиваем файлы, размер будет 20.7Kb(523b gzipped), а браузеры загрузят страницу с такой скоростью:
Chrome — 203ms(-29%), FF — 208ms(-41%), IE — 680ms(-19%);

Тест №3.
Размер одного файла — 207Kb
Gzipped(including http headers) — 1.14Kb
Количество подключенных файлов — 10

Chrome

onload = 368ms
connecting+waiting = ~70-80ms
receiving = ~30ms

FF

onload — 1.03s
connecting+waiting = ~88ms
receiving = ~0ms (???Firebug issue?)

IE

onload — 5.55s
connecting+waiting = ~300ms
receiving = ~8.4ms

Если склеить файлы, размер будет 2.2Mb(8.2Kb gzipped), а браузеры загрузят страницу с такой скоростью:
Chrome — 401ms(+11%), FF — 919ms(-9%), IE — 1.29s(-77%);

Тест №4.(из области фантастики)
Размер одного файла — 4.9Мb
Gzipped(including http headers) — 17.3Kb
Количество подключенных файлов — 10

Chrome

onload = 6.3s
connecting+waiting = ~2s
receiving = ~2.3s

FF

onload — ~19s
connecting+waiting = ~600ms
receiving = ~0ms (???Firebug issue?)

IE

onload — 21s
connecting+waiting = ~4s
receiving = ~3s

Если склеить файлы, размер будет 48.5Mb(169.2Kb gzipped), а браузеры загрузят страницу с такой скоростью:
Chrome — 6.78s(+7%), FF — 19.65s(+3%), IE — 4.9s(-77%);

В большинстве случаев рекомендация склеивать файлы себя оправдывает, но на больших и сверхбольших подключаемых файлах механизм распараллеливания запросов дает лучшие результаты по скорости загрузки. Иначе обстоит картина для пользователей IE. В силу особенностей механизма отправки запросов параллельно, склеивание файлов дает ощутимый прирост в скорости загрузки.