Опубликованное недавно исследование базы паролей университета Карнеги-Меллон выявило несколько интересных корреляций между демографическими характеристиками и качеством паролей, которые используют люди. Уникальность этого исследования состоит в том, что все акккаунты, пароли к которым исследовались, принадлежат сотрудникам и студентам университета Карнеги-Меллон. Эти пароли использовались для доступа к весьма важным данным и функциям на университетском сайте, ограничения на длину и сложность пароля при регистрации были довольно строгими. В базе университета хранились подробные персональные данные всех пользователей, а в логах сервера аутентификации — информация о скорости ввода паролей, удачных и неудачных попытках входа. Всего было исследовано около 40 000 паролей от действующих и отключенных аккаунтов

Обычные базы паролей, доступные после утечек со взломанных сайтов, содержат много мусора в виде одноразовых аккаунтов случайных посетителей с паролями вроде «12345» или «password» и наоборот, мало информации о пользователях — обычно только логин или адрес электронной почты.

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

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

В исследовательском центре IBM имени Томаса Уотсона разработали технологию получения однослойных листов графена размером до 10 сантиметров и нанесения их на кремниевую подложку. Эта технология может стать основой для массового производства графена и появления на рынке электронных устройств на его основе.

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

В следующем году TrueCrypt исполнится десять лет. Несмотря на столь солидный возраст, за всё это время так и не был проведён формальный независимый аудит кода программы. Как и во многих других проектах Open Source разработчики постоянно работают над новым функционалом и исправлением ошибок, но не находят времени, денег и возможностей для подобных мероприятий. У TrueCrypt есть и другие проблемы — не совсем ясная и понятная лицензия, нет официального репозитория кода на Гитхабе или другой подобной площадке, не формализован процесс компиляции и сборки, из-за чего нельзя гарантировать идентичность работы программы на разных платформах.

Всё это, а так же откровения Эдварда Сноудена о тотальной слежке и закладках АНБ в криптографическом софте, которые бросают тень в том числе и на TrueCrypt, вдохновило Кеннета Уайта, программиста и специалиста по биотехнологиям, и Мэтью Грина, профессора Университета Джонса Хопкинса и криптолога, начать краудфандинговую кампанию, цель которой — провести полный аудит кода TrueCrypt, привести в порядок его лицензию, разработать и документировать стандартный алгоритм сборки бинарников на всех платформах и создать публичный репозиторий кода. Идею поддержала и команда разработчиков TrueCrypt.

Прошлым летом учёные из лаборатории интеллектуальных систем Федеральной политехнической школы Лозанны продемонстрировали прототип летающего робота, который не боится падений и столкновений с препятствиями. Суть идеи — робота окружает лёгкий каркас из углеродного волокна, который защищает его от повреждений, а после падений робот переворачивается в рабочее положение с помощью упругих ног.

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

Агентство DARPA объявило о начале новой масштабной программы в формате «Grand Challenge». Цель программы Cyber Grand Challenge — создание систем компьютерной безопасности, способных автоматически анализировать и исправлять уязвимости. Сегодня этой работой занимаются эксперты высокой квалификации, и закрытие «дыр» занимает дни и месяцы. DARPA хочет сократить этот срок до часов и минут.

Системы безопасности нового поколения должны анализировать ПО и компьютерные сети, создавать патчи, тестировать и применять их без участия человека. Это звучит как фантастика, однако стоит вспомнить прошлые конкурсы в этом же формате — в 2004, 2005 и 2007 годах целью DARPA Grand Challenge стало создание полностью автономного автомобиля. В них участвовала в том числе и команда Стэнфордского университета, возглавляемая Себастьяном Труном, который продолжил работу над созданием автономного автомобиля в корпорации Google.

От переводчика: Это двенадцатая, последняя статья из цикла о 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, как развернуть его на сервере? Вместо того, чтобы использовать готовое PaaS-решение, наша команда создала собственную инфраструктуру поверх Amazon EC2. Сейчас мы расскажем подробнее о том, как мы это сделали.

Мы представим вам awsbox — минималистичный слой PaaS-инфраструктуры для Node.js, который сейчас обслуживает пару дюжин некритичных сервисов Mozilla. Awsbox разработан для того, чтобы предоставить простоту и удобство развёртывания, характерные для PaaS, не теряя при этом гибкости кастомизированной инфраструктуры.

От переводчика: Это одиннадцатая статья из цикла о 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"

---

Использование строк

Итак, сначала мы подключили к нашему приложению модуль i18n-abide и обернули строки в вызовы gettext. Затем наша команда переводчиков перевела эти строки и у нас есть готовый перевод для каждого языка.

Теперь давайте заставим наше приложение Node.js работать с локализованными строками. Переводы в виде po-файлов лежат в файловой системе в таком виде:

locale
  en
    LC_MESSAGES
      messages.po
  de
    LC_MESSAGES
      messages.po
  es
    LC_MESSAGES
      messages.po

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

• на стороне сервера с помощью всё той же функции gettext из модуля i18n-abide;
• на стороне клиента с помощью скрипта gettext.js, который также входит в состав i18n-abide.

Оба этих метода требуют, чтобы строки были в формате JSON. При переводе на стороне сервера они загружаются при старте приложения, а клиент загружает их с помощью HTTP-запросов (или можно включить их в минифицированный файл JavaScript в процессе сборки).

Так как наша система перевода совместима с GNU Gettext, есть ещё и третий путь — модуль node-gettext. Он довольно эффективен при переводе на стороне сервера.

Дальше мы будем рассматривать первый способ, так как это наиболее привычный способ использования i18n-abide.

Исследователи из Федеральной политехнической школы Лозанны построили статистическую модель, предсказывающую успех или провал кампании на Кикстартере на основе динамики финансирования и социальных взаимодействий. Более ранние попытки предсказать итог кампаний совместного финансирования опирались на статические показатели, то есть те, которые известны до начала кампании: размер собираемой суммы, наличие видео, тематика. Такие модели достигали точности в 68%.

От переводчика: Это деcятая статья из цикла о 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 мы узнали, как использовать модуль i18n-abide в нашем коде. Наша работа, как программистов, фактически закончилась на том, что мы обернули строки в шаблонах и коде приложения в вызовы gettext(). Но работа по локализации и переводу приложения только начинается.

Инструментарий

Инструментарий локализации команды Mozilla Persona совместим с теми инструментами, которые используются в остальном сообществе Mozilla, и при этом сохраняет преимущества в дружественности и гибкости, присущие Node.

Проекту Mozilla уже почти 15 лет, и наша команда локализаторов и переводчиков одна из самых больших (и клёвых) в мире Open Source. Поэтому у нас широко используются давно привычные, можно даже сказать старинные и причудливые инструменты.

От команды Гитхаба всё чаще слышны высказывания о том, что совместная разработка ПО — далеко не единственный сценарий применения их сайта. Сооснователь и CEO Гитхаба Том Престон-Вернер заявил недавно: «Мы хотим, сделать Гитхаб настолько гибким и простым, чтобы им могли пользоваться юристы, чиновники, кто угодно… Сейчас мы постоянно обсуждаем со множеством людей то, как они используют Гитхаб, и как ещё его можно использовать».

Уже есть несколько примеров использования Гитхаба не для разработки софта, а для написания книг, законов, публикации наборов данных. А 15 октября на Гитхабе открылся раздел government.github.com, специально предназначенный для проектов, связанных с электронным правительством, открытыми данными, гражданскими инициативами и законотворчеством. Список государственных учреждений, общественных организаций, правительств и муниципалитетов, использующих Гитхаб, уже насчитывает десятки наименований.

Само явление акустической левитации — полёта с использованием энергии звуковых волн достаточно большой интенсивности — известно довольно давно. Однако учёным из Швейцарской высшей технической школы Цюриха удалось добиться не просто парения предметов на гребне стоячей волны, а управляемого полёта. Их установка состоит из массива ультразвуковых излучателей под управлением компьютера. Согласованно изменяя частоту и интенсивность разных излучателей, можно перемещать и вращать предметы, не прикасаясь к ним. Учёные продемонстрировали управляемую левитацию капелек жидкостей и крупинок твёрдых материалов, а так же вращение деревянной зубочистки — для акустической левитации, в отличие от электромагнитной, совершенно не важны электрические и магнитные свойства предметов.

Типичный протез ладони стоит в Великобритании от 7.000 до 70.000 фунтов стерлингов (10.000 — 100.000 $). Дорогие материалы, отсутствие массового спроса, низкая конкуренция, необходимость индивидуальной подгонки каждого изделия делают полноценный протез весьма дорогим. Именно поэтому 3D-печать для изготовления протезов имеет огромный потенциал, считает британский робототехник Джоэл Гиббард. Несколько часов назад успешно завершилась его краудфандинговая кампания на IndieGoGo по созданию Dextrus — открытого и доступного протеза ладони. Большая его часть распечатана на 3D-принтере. Dextrus имеет независимые приводы для каждого из пальцев, тактильную обратную связь, позволяющую автоматически регулировать силу сжатия и управляется биоэлектрическим методом, считывая сигналы через кожу. При этом он будет стоить в несколько десятков раз дешевле коммерческих аналогов, а все спецификации, модели и чертежи будут в свободном доступе.

От переводчика: Это девятая статья из цикла о 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, локализованный для множества локалей. У нашей команды были весьма специфические запросы, и поэтому мы не стали использовать существующие библиотеки для локализации.

От переводчика: Это восьмая статья из цикла о 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. [От переводчика: а на Хабре очень кстати статья, посвящённая производительности веб-шрифтов]

Скандал вокруг программы PRISM может подорвать позиции США на мировом рынке облачных услуг. Об этом говорится в докладе ITIF — авторитетного американского аналитического центра в области информационных технологий и инноваций. Опросы, проведённые организацией Cloud Security Alliance, свидетельствуют о том, что 10% неамериканских компаний уже отказались от некоторых облачных услуг, предоставляемых американскими провайдерами. Число тех, кто колеблется, в несколько раз больше — информация о тотальной прослушке интернета американскими спецслужбами внушает опасения 56% опрошенных. 36% компаний из США отметили, что испытывают затруднения в работе с иностранными клиентами.

От переводчика: Это седьмая статья из цикла о 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.

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

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-атаки. Первый шаг к борьбе с такими атаками — написание сервера, который не падает.

От переводчика: Это четвёртая статья из цикла о 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 автоматически делать то, что вам раньше доводилось делать вручную.