От переводчика: Это вторая статья из цикла о Node.js от команды Mozilla Identity, которая занимается проектом Persona. Эта статья написана по мотивам выступления Ллойда Хилайеля на конференции Node Philly 2012 в Филадельфии.

Все статьи цикла:

1. "Охотимся за утечками памяти в Node.js"
2. "Нагружаем Node под завязку"
3. "Храним сессии на клиенте, чтобы упростить масштабирование приложения"
4. "Производительность фронтэнда. Часть 1 — конкатенация, компрессия, кэширование"
5. "Пишем сервер, который не падает под нагрузкой"
6. "Производительность фронтэнда. Часть 2 — кешируем динамический контент с помощью etagify"
7. "Приручаем конфигурации веб-приложений с помощью node-convict"
8. "Производительность фронтенда. Часть 3 — оптимизация шрифтов"
9. "Локализация приложений Node.js. Часть 1"
10. "Локализация приложений Node.js. Часть 2: инструментарий и процесс"
11. "Локализация приложений Node.js. Часть 3: локализация в действии"
12. "Awsbox — PaaS-инфраструктура для развёртывания приложений Node.js в облаке Amazon"

---

Процесс Node.js выполняется на единственном ядре процессора, так что построение масштабируемого сервера на Node требует особой заботы. Благодаря возможности писать нативные расширения и продуманному набору API для управления процессами, есть несколько разных способов заставить Node выполнять код параллельно. Мы рассмотрим их в этой статье.

Кроме того, мы представим модуль compute-cluster — маленькую библиотеку, которая облегчает управление коллекцией процессов для выполнения распределённых вычислений.

Постановка задачи

Для Persona нам было необходимо создать сервер, который справился бы с обработкой множества запросов со смешанными характеристиками. Мы выбрали для этой цели Node.js. Нам надо было обрабатывать два основных типа запросов: «интерактивные», которые не требовали сложных вычислений и должны были выполняться быстро, чтобы интерфейс приложения был отзывчивым, и «пакетные», которые отнимали примерно пол-секунды процессорного времени и могли быть ненадолго отложены без ущерба для удобства пользователя.

В поисках наилучшей архитектуры приложения мы долго и тщательно обдумывали способы обработки этих типов запросов с учётом юзабилити и стоимости масштабирования и в конце концов сформулировали четыре основных требования:

• Насыщение. Наше решение должно было использовать все доступные ядра процессора.
• Отзывчивость. Пользовательский интерфейс должен оставаться отзывчивым. Всегда.
• Отказоустойчивость. Когда нагрузка зашкаливает, мы должны нормально обслужить столько клиентов, сколько сможем, а остальным показать сообщение об ошибке.
• Простота. Решение должно легко и постепенно интегрироваться в уже работающий сервер.

Вооружившись этими требованиями, мы можем осмысленно сравнивать разные подходы.

От переводчика: Это восьмая статья из цикла о Node.js от команды Mozilla Identity, которая занимается проектом Persona.

Все статьи цикла:

1. "Охотимся за утечками памяти в Node.js"
2. "Нагружаем Node под завязку"
3. "Храним сессии на клиенте, чтобы упростить масштабирование приложения"
4. "Производительность фронтэнда. Часть 1 — конкатенация, компрессия, кэширование"
5. "Пишем сервер, который не падает под нагрузкой"
6. "Производительность фронтэнда. Часть 2 — кешируем динамический контент с помощью etagify"
7. "Приручаем конфигурации веб-приложений с помощью node-convict"
8. "Производительность фронтенда. Часть 3 — оптимизация шрифтов"
9. "Локализация приложений Node.js. Часть 1"
10. "Локализация приложений Node.js. Часть 2: инструментарий и процесс"
11. "Локализация приложений Node.js. Часть 3: локализация в действии"
12. "Awsbox — PaaS-инфраструктура для развёртывания приложений Node.js в облаке Amazon"

---

Мы смогли уменьшить объем шрифтов для Persona на 85%, с 300 до 45 килобайт, используя подмножества шрифтов. Эта статья рассказывает о том, как именно мы это сделали, и какие мы использовали инструменты.

Представляем connect-fonts

Connect-fonts — это middleware для Connect, которое улучшает производительность @font-face, раздавая клиентам подобранные специально для их языка подмножества шрифтов, уменьшая тем самым их размер. Connect-fonts также генерирует специфические для локали и браузера стили @font-face и CORS-заголовки для Firefox и IE9+. Для раздачи подмножеств шрифтов создаются так называемые font packs — поддиректории с подмножествами шрифтов плюс простой конфигурационный файл JSON. Некоторые наборы распространённых open source-шрифтов доступны в готовом виде в пакете npm, впрочем, создавать свои пакеты совсем нетрудно.

Если вы не слишком хорошо ориентируетесь в работе со шрифтами в интернете, мы собрали небольшую коллекцию ссылок по теме @font-face. [От переводчика: а на Хабре очень кстати статья, посвящённая производительности веб-шрифтов]

От переводчика: Это шестая статья из цикла о Node.js от команды Mozilla Identity, которая занимается проектом Persona.

Все статьи цикла:

1. "Охотимся за утечками памяти в Node.js"
2. "Нагружаем Node под завязку"
3. "Храним сессии на клиенте, чтобы упростить масштабирование приложения"
4. "Производительность фронтэнда. Часть 1 — конкатенация, компрессия, кэширование"
5. "Пишем сервер, который не падает под нагрузкой"
6. "Производительность фронтэнда. Часть 2 — кешируем динамический контент с помощью etagify"
7. "Приручаем конфигурации веб-приложений с помощью node-convict"
8. "Производительность фронтенда. Часть 3 — оптимизация шрифтов"
9. "Локализация приложений Node.js. Часть 1"
10. "Локализация приложений Node.js. Часть 2: инструментарий и процесс"
11. "Локализация приложений Node.js. Часть 3: локализация в действии"
12. "Awsbox — PaaS-инфраструктура для развёртывания приложений Node.js в облаке Amazon"

---

Возможно, вам известно, что Connect ставит ETag-и на статический контент, но не динамический. К сожалению, если вы динамически генерируете локализованные версии статических страниц, они не кешируются вообще, если только вы не решите генерировать их все заранее, на стадии сборки проекта. Этого вполне можно избежать.

Эта статья посвящена etagify — модулю middleware для Connect, который генерирует ETag-и на лету на основе MD5-хешей ответов, и хранит эти хеши в памяти. Etagify избавляет от лишней рутины при сборке проекта, предельно прост в использовании и увеличивает производительность больше, чем можно было бы ожидать (в своих тестах мы получили ускорение загрузки страниц на 9%):

myapp = require('express').createServer();
myapp.use(require('etagify')());
...
app.get('/about', function(req, res) {
  res.etagify(); 
  var body = ejs.render(template, options);
  res.send(body);
});

От переводчика: Это пятая статья из цикла о Node.js от команды Mozilla Identity, которая занимается проектом Persona.

Все статьи цикла:

1. "Охотимся за утечками памяти в Node.js"
2. "Нагружаем Node под завязку"
3. "Храним сессии на клиенте, чтобы упростить масштабирование приложения"
4. "Производительность фронтэнда. Часть 1 — конкатенация, компрессия, кэширование"
5. "Пишем сервер, который не падает под нагрузкой"
6. "Производительность фронтэнда. Часть 2 — кешируем динамический контент с помощью etagify"
7. "Приручаем конфигурации веб-приложений с помощью node-convict"
8. "Производительность фронтенда. Часть 3 — оптимизация шрифтов"
9. "Локализация приложений Node.js. Часть 1"
10. "Локализация приложений Node.js. Часть 2: инструментарий и процесс"
11. "Локализация приложений Node.js. Часть 3: локализация в действии"
12. "Awsbox — PaaS-инфраструктура для развёртывания приложений Node.js в облаке Amazon"

---

Как написать приложение Node.js, которое будет продолжать работать даже под невозможной нагрузкой? В этой статье показана методика и библиотека node-toobusy, её воплощающая, суть которой наиболее кратко может быть передана этим фрагментом кода:

var toobusy = require('toobusy');
 
app.use(function(req, res, next) {
  if (toobusy()) res.send(503, "I'm busy right now, sorry.");
  else next();
});

В чём заключается проблема?

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

Это может быть и злонамеренный всплеск трафика, например от DoS-атаки. Первый шаг к борьбе с такими атаками — написание сервера, который не падает.

(Дата оригинала — 7.10.2013. У оригинала — очень оживлённая дискуссия в комментариях)

Фронтенд-разработчики имеют довольно долгую и сложную историю в программировании. Долгое время отправляемое в браузер было так легко отобразить, что не было настоящей потребности в этой специализации. Многие считали, что они были просто графическими дизайнерами с немного другими выразительными средствами. Мысль о том, что они могли в один прекрасный день специализироваться в веб-технологиях, HTML, CSS, Javascript — была смехотворной; в лучшем случае — пользовательский интерфейс их удел или, в конце концов, кто-то мог специализироваться на том и другом и иметь эту работу.

От переводчика: Это седьмая статья из цикла о Node.js от команды Mozilla Identity, которая занимается проектом Persona.

Все статьи цикла:

1. "Охотимся за утечками памяти в Node.js"
2. "Нагружаем Node под завязку"
3. "Храним сессии на клиенте, чтобы упростить масштабирование приложения"
4. "Производительность фронтэнда. Часть 1 — конкатенация, компрессия, кэширование"
5. "Пишем сервер, который не падает под нагрузкой"
6. "Производительность фронтэнда. Часть 2 — кешируем динамический контент с помощью etagify"
7. "Приручаем конфигурации веб-приложений с помощью node-convict"
8. "Производительность фронтенда. Часть 3 — оптимизация шрифтов"
9. "Локализация приложений Node.js. Часть 1"
10. "Локализация приложений Node.js. Часть 2: инструментарий и процесс"
11. "Локализация приложений Node.js. Часть 3: локализация в действии"
12. "Awsbox — PaaS-инфраструктура для развёртывания приложений Node.js в облаке Amazon"

---

В этой статье из цикла о Node.js мы рассмотрим модуль node-convict, который помогает управлять конфигурациями приложений Node.js. Он предоставляет прозрачные настройки по умолчанию и встроенную типизацию, чтобы было легче находить и исправлять ошибки.

Постановка задачи

Есть две основные проблемы, которые создают необходимость в конфигурации приложений:

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

Эти проблемы можно решить, инициализируя некоторые переменные в зависимости от текущего окружения и используя переменные окружения для хранения конфиденциальных данных. Общепринятый в среде Node.js шаблон для реализации этого подхода состоит в создании модуля, который экспортирует конфигурацию:

var conf = {
  // окружение приложения - 
  // "production", "development", или "test
  env: process.env.NODE_ENV || "development",
 
  // IP адрес
  ip: process.env.IP_ADDRESS || "127.0.0.1",
 
  // Порт
  port: process.env.PORT || 0,
 
  // Настройки БД
  database: {
    host: process.env.DB_HOST || "localhost:8091"
  }
};
 
module.exports = conf;

Это работает неплохо, но есть ещё пара проблем:

• Что если в конфигурации указаны некорректные данные? Мы можем сберечь время и нервы, обнаруживая ошибки как можно раньше.
• Насколько легко разобраться в конфигурации администраторам, тестировщикам и другим членам большой команды, когда им надо менять настройки или искать дефекты? Более декларативный и лучше документированный формат сделал бы их жизнь легче.

От переводчика: Это четвёртая статья из цикла о Node.js от команды Mozilla Identity, которая занимается проектом Persona. Эта статья о том, как увеличить скорость загрузки ресурсов сайта и модуле connect-cachify, созданном в Mozilla для этой цели.

Все статьи цикла:

1. "Охотимся за утечками памяти в Node.js"
2. "Нагружаем Node под завязку"
3. "Храним сессии на клиенте, чтобы упростить масштабирование приложения"
4. "Производительность фронтэнда. Часть 1 — конкатенация, компрессия, кэширование"
5. "Пишем сервер, который не падает под нагрузкой"
6. "Производительность фронтэнда. Часть 2 — кешируем динамический контент с помощью etagify"
7. "Приручаем конфигурации веб-приложений с помощью node-convict"
8. "Производительность фронтенда. Часть 3 — оптимизация шрифтов"
9. "Локализация приложений Node.js. Часть 1"
10. "Локализация приложений Node.js. Часть 2: инструментарий и процесс"
11. "Локализация приложений Node.js. Часть 3: локализация в действии"
12. "Awsbox — PaaS-инфраструктура для развёртывания приложений Node.js в облаке Amazon"

---

В этой статье мы поговорим о производительности фронтэнда и представим инструменты, созданные в Mozilla для того, чтобы сделать сайт Persona настолько быстрым, насколько возможно. Мы опишем работу с connect-cachify — модулем, автоматизирующим некоторые из важнейших аспектов, обеспечивающих производительность фронтэнда.

Но сначала окинем взглядом наиболее распространённые пути улучшения производительности. Если у вас уже есть опыт оптимизации фронтэнда, можете пропустить эти разделы и перейти в конец статьи, где описано, как с помощью connect-cachify автоматически делать то, что вам раньше доводилось делать вручную.

От переводчика: Это девятая статья из цикла о Node.js от команды Mozilla Identity, которая занимается проектом Persona.

Все статьи цикла:

1. "Охотимся за утечками памяти в Node.js"
2. "Нагружаем Node под завязку"
3. "Храним сессии на клиенте, чтобы упростить масштабирование приложения"
4. "Производительность фронтэнда. Часть 1 — конкатенация, компрессия, кэширование"
5. "Пишем сервер, который не падает под нагрузкой"
6. "Производительность фронтэнда. Часть 2 — кешируем динамический контент с помощью etagify"
7. "Приручаем конфигурации веб-приложений с помощью node-convict"
8. "Производительность фронтенда. Часть 3 — оптимизация шрифтов"
9. "Локализация приложений Node.js. Часть 1"
10. "Локализация приложений Node.js. Часть 2: инструментарий и процесс"
11. "Локализация приложений Node.js. Часть 3: локализация в действии"
12. "Awsbox — PaaS-инфраструктура для развёртывания приложений Node.js в облаке Amazon"

---

Знаете ли вы, что продукты и сервисы Mozilla локализованы для 90 языков? Локализация включает в себя:

• текст, переведённый на региональные вариации и диалекты языков;
• рендеринг страниц с учётом написания справа налево;
• пуленепробиваемый дизайн, способный вместить тексты любой длины;
• заголовки, метки и текст на кнопках, подобранные для локальных аудиторий.

В этой серии из трёх статей, посвящённых локализации, я расскажу о технических аспектах создания многоязычного приложения Node.js.

Мы будем использовать общепринятые термины «интернационализация» (i18n) и «локализация» (l10n). Интернационализация — это набор технических приёмов, делающих возможной последующую локализацию, то есть собственно перевод и адаптацию для конкретного языка.

Mozilla Persona — веб-сервис на Node.js, локализованный для множества локалей. У нашей команды были весьма специфические запросы, и поэтому мы не стали использовать существующие библиотеки для локализации.

С нами связался хабражитель Александр, блогер и предприниматель из Екатеринбурга, который в ноябре переезжает в Долину и хотел задать свои вопросы. Получилось вот такое интервью-ответ на вопросы о Кремниевой Долине, предпринимательстве, русскоговорящем бизнес-сообществе AmBAR, предпринимательстве в России и российских ассоциациях. На вопросы отвечал тот, кто сам не так давно переехал в Кремниевую Долину и имеет т.н. «свежий взгляд».

Вообще, всем, кто хочет получить некоторый ликбез о Кремниевой Долине, советуем почитать вот эту очень вдохновенную статью основателя Evernote (компании, стоимостью в 2 млрд. долларов) Степана Пачикова, которую опубликовали в «Огоньке» в 1995 году. А у вас есть какие-то вопросы о Кремниевой Долине? Не стесняйтесь задавать в комментариях.

Итак, поехали.

Привет!

«Хабрахабр» не понаслышке знает, с какими трудностями приходится сталкиваться стартапам в самом начале их пути. Сложно посчитать количество интересных проектов, которые не «выстрелили», не справившись с проблемами: не смогли заявить о себе широкой общественности, не встретили инвестора, не обрели аудиторию и достаточного фидбека, не нашли программиста, дизайнера или менеджера проекта.

Более 10 лет занимаясь ядрёной смесью из математики, программирования и управления проектами – всем тем, что входит в современное понимание Информационных Технологий — я сформулировал простые правила, которые считаю подходящими для любого профессионала, связанного с ИТ.

JavaScript принято считать прототип-ориентированным языком программирования. Но, как ни странно, этим подходом практически никто не пользуется: большинство популярных JS-фреймворков явно или неявно оперируют классами.
В этой статье я хочу рассказать об альтернативном способе программирования на JavaScript, без использования классов и конструкторов — чистым прототипным ООП и особенностях его реализации на ECMA Script 5.

Разработка

Я расскажу о цикле разработки через Github, который я использую. Он был проверен в течении года на командах разного размера: 3 — 14 человек.

Существует 2 основных ветки: master и dev.

master — стабильная ветка, готовая к выкатыванию на production сервер в любой момент.

dev — ветка, над которой в данный момент работает команда.

Итак, в начале разработки master и dev ветки идентичны.

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

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

Библиотека WebGL позволяет создавать в браузере удивительные 3D игры, сцены и эффекты. Пока большинство из них just for fun, но некоторые могут быть уже сегодня использоваться на живых сайтах. В этом топике собраны наиболее интересные примеры использования WebGL, спасибо двум постам Дэвида Уолша (David Walsh) и сайту WebGL Experiments.

Google Maps Cube

Необычная игра, где нужно гонять шарик по лабиринту из улиц Google Maps, доставляя метку в определенные места на карте. И все это расположено на кубе. Осторожно, можно залипнуть надолго!

Сегодня пользователи все чаще читают электронные письма на мобильных устройствах. Каково бывает просмотр большого HTML-email'а на телефоне? Приходится много масштабировать и скроллить, в целом читать становится очень неудобно. Поэтому и письма электронной почты следует делать адаптивными.

Многие заметили, что на YouTube и на Medium появился небольшой новый элемент UI — прогресс-бар в виде тонкой цветной полоски в самом верху страницы, который примостился прямо под панелью браузера.

Внимание к новому элементу привлек недавний популярный пост New UI Pattern: Website Loading Bars на UsabilityPost. Как выяснилось, причина использования прогресс-бара в том, что вместо загрузки новой страницы содержимое подгружается через JavaScript, и поэтому собственный индикатор браузера о загрузке страницы может не срабатывать. Чтобы у пользователя не возникало ощущения, будто страница «зависла», эту функцию переложили на плечи маленького UI-приема.

Теперь у всех желающих появилась возможность быстро сделать на своем сайте точно такой же прогресс-бар благодаря плагину NProgress.js [Демо][GitHub].

Всем доброго времени суток. Как-то так получилось, за последнее время я увидел много интересных и полезных инструментов/библиотек/событий, которыми я хотел поделиться на Хабре. Все эти темы по отдельности, на мой взгляд, не заслуживали целой статьи. Но каждая из них достойна внимания и может кому нибудь пригодиться. В итоге получился небольшой дайджест:

Prepros

Великолепное приложение препроцессор для CSS, JS. Компилирует файлы следующих типов: LESS, Sass, SCSS, Stylus, Jade, Slim, Coffeescript, LiveScript, Haml. Минифицирует JS на лету, при каждом изменении файла. Оптимизирует изображения. Доступен для Windows и Mac, а также как расширение для Chrome. Плюс ко всему создает HTTP сервер, для тестирования сайта на разный устройствах. Бесплатная замена CodeKit'у и Ghostlab'у вместе взятых, что в сумме позволит Вам сэкономить $75.

Я думаю, что на многих сайтах пользователя спросят его физический адрес. Для доставки ли, для отсылки бумажного спама уведомлений ли. И, в общем-то — это мелочь. Вбил индекс, Москва, область, район, село, улица, дом, квартира. Казалось бы, что тут упрощать, каждый вроде помнит свой адрес, трудно ли его вбить? Но дьявол, как всегда, кроется в мелочах: пользователь опечатывается в адресе, посылка уходит не туда, лучи «добра» идут вам в обратную связь и вообще жизнь плохеет.

Приглядитесь к первой части адреса — индексу. В этом наборе из шести цифр уже есть область, район и город/село. Их можно подставить автоматом. Этим мы убъём сразу двух зайцев:

• Убережём пользователя от ошибок (при вводе неверного индекса он сразу заметит, что город-то не его), что, в случае доставки письма (а то и посылки), может здорово её ускорить (пока её по неверному индексу зашлют, да пока разберутся, что не туда заслали, да отправят туда — пользователь вам всю плешь проест)
• пользователю будет приятно, что о нём заботятся :-)

Дело за малым: нам нужна база почтовых индексов.

И она есть! Всамделишняя, электронная и, главное, официальная база индексов от Почты России.