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

Я хотел бы поделиться нашим опытом использования Go в течение двух лет в продакшне Iron.io. Мы одна из первых компаний, ставших использовать Go (golang) в высоконагруженных сервисах. Когда в Iron.io было принято решение об использовании этого языка, мы не знали, чего ожидать в долгосрочной перспективе, но до сих пор все идет отлично.

Я уже немного писал об этом в предыдущем посте о переходе на Go с Ruby. Но сейчас мне хотелось бы поговорить о конкретных вещах, за которые мы любим этот язык, о которых узнали во время его использования

Доброго времени суток, уважаемые хабражители. Хочу поделиться с вами одной замечательной находкой на GitHub — SVG.js — удобная манипуляция и анимация SVG. Хочется сказать о трех вещах, которые сосредоточили мое внимание на этой библиотеке. Самое простое и важное это то, что с появлением retina дисплеев SVG становится популярнее, более нужным, чем раньше. SVG.min.js весит 34кб и 9кб в Gzip, что в разы меньше Raphaël и что можно пожертвовать для дизайна и эффектов. Минифицированный SVG.filter.js размером в 3кб является прекрасным кроссбраузерным аналогом для свойства webkit-filter.

— Мы получаем больше миллиона твитов в день, и наш сервер просто не успевает их обрабатывать. Поэтому мы хотим установить на кластер Hadoop и распределить обработку.

Речь шла о вычислительно тяжёлом сентиментном анализе, поэтому я мог поверить, что у одного сервера действительно не хватает CPU, чтобы справиться с большим потоком твитов.

— А что вы собираетесь делать с уже обработанными данными?
— Скорее всего, мы будем складывать их в MySQL, как делали это раньше, или даже удалять.
— Тогда вам определённо не нужен Hadoop.

Мой бывший коллега был далеко не первым, кто говорил про распределённые вычисления на Hadoop. И каждый раз я видел полное непонимание того, зачем была придумана и разработана эта платформа.

Вот, набрел на просторах гитхаба на интересную библиотеку (GitHub). Дальше следует немного слов от автора.
Jedi — это инструмент, который можно использовать для автодополнения кода Python в IDE/редакторах. Jedi работает. Jedi быстр. Он понимает все основные элементы синтаксиса Python, в том числе встроенные функции.
Кроме того, Jedi поддерживает две разные goto функции и имеет поддержку переименования, а также поддерживает Pydoc и другие фишки IDE.
Jedi использует очень простой API, чтобы соединиться с IDE. Основная реализация — это VIM-плагин, использующий автозавершение Jedi. Я призываю использовать Jedi в ваших IDE. Это очень просто. Если возникнут проблемы (в том числе с лицензированием) — свяжитесь со мной.
Jedi можно использовать с такими редакторами:

• Vim (jedi-vim, YouCompleteMe)
• Emacs (Jedi.el)
• SynWrite (SynJedi)
• Sublime Text (Sublime JEDI [ST2 + ST3], anaconda [only ST3])
  
  А также присутствует в проекте wdb
  

Жёлтый заголовок: исследуем MMORPG, добавляем читерских фич и пишем неуловимого бота.

С момента первого обзора среды (этот обзор был опубликован более чем год назад) IDE Brackets превратилась из просто многообещающего прототипа во вполне полноценный инструмент для разработки web-приложений. Недавно также был опубликован пост, в котором вскользь упоминалась эта среда, но сам текст и комментарии были так скупы на описание проекта, что я посчитал полезным рассказать сообществу о возможностях этой IDE более подробно.

Немного информации о том, что из себя представляет IDE Brackets. Среда разрабатывается на web-платформе (HTML, CSS и JavaScript) для web-программистов с использованием Chromium Embedded Framework (CEF) компанией Adobe. В основе Brackets лежат такие проекты, как CodeMirror, jQuery, require.js, Bootstrap, Node.js. Исходные коды распространяются под open source лицензией MIT. Основная цель проекта — упрощение процесса web-разработки. Работа над IDE идёт по методологии scrum (спринтами по 2.5 недели). Среда вполне стабильна — сами разработчики IDE Brackets стали использовать её в своей повседневной работе уже достаточно давно. Скачать среду можно отсюда.

Основные моменты: среда стала доступна для Linux, появилась поддержка Node.js, реализовано интеллектуальное автодополнение кода для HTML, CSS, JavaScript, сообщество создало более сотни полезных плагинов, плюс в разработке находится продвинутая система для упрощения создания макетов с отзывчивым дизайном, которая уже успела произвести WOW-эффект на тех, кто её видел.

(под катом скриншоты ~1.5Mb)

Оригинальный pdf (на английском)
Переведённый pdf (на русском)

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

Инструменты

Colour Lovers — старый и функциональный инструмент для подбора цветовых схем. Аналоги — Colourcode, Color Scheme Designer и конечно Kuler. Подобных сайтов великое множество, но эти, на мой взгляд, самые удобные.

В этой статье очень подробно описано пошаговое создание адаптивного меню для сайта с несколькими вариантами компоновки элементов (в зависимости от размера экрана девайса). Для поддержки retina-экранов используется иконочный шрифт.



Демо / Скачать исходники

Разрабатывая постоянно сталкиваешься с разнообразными задачами, которые часто решить в лоб не удаётся. Но многие задачи уже были решены кем-то — нужно только найти это решение.

Так, день за днём я насобирал небольшую коллекцию батареек, которые сильно облегчили мне жизнь. Чем и спешу поделиться:

Node.js развивается, и, вполне уже можно экспериментировать с написанием графических приложений либо каких-то консольных утилит и сервисов. В процессе разработки может возникнуть необходимость использовать какие-то системные вызовы, например, к WMI (к WMI нельзя обратиться напрямую из node.js, и запросы WMI могут быть долгими, что заблокирует event loop, и, например, если связь у Вас через веб-сокеты, связь может оборваться). Тут существует несколько вариантов. Можно воспользоваться модулем (например, node-ffi) и попробовать поиграться с ним. Есть ещё способ, точнее, костыль. В Windows существует так называемый WScript (Windows Script Host) — это компонент Windows, предназначенный для запуска, например, JScript, VBScript. JScript может обращаться к WMI напрямую, так что мы имеем возможность запустить child_process, в котором будет работать JScript, и получать от него данные (формировать, например, JSON и отправлять его строкой), но это костыль, бессмысленный и беспощадный. И третий способ — это нативный модуль. Я не буду описывать, как получить данные от WMI, а опишу что-нибудь менее ёмкое. Кому интересно — прошу под кат.

Многим уже надоело лазить по куче сайтов и скачивать js библиотеки и плагины. Да и таскать когда-то скачанные, но уже давно протухшие версии не очень круто. Эти проблемы решает bower.

Но с ним тоже многое нужно делать вручную: следить за components каждого проекта, руками дёргать bower install. После pip с requirements.txt это делать даже как-то лень.

Поэтому представляю вам django-bower, который берёт на себя установку и обновление bower пакетов по списку из settings и прозрачную работу с staticfiles.

Очень многие разработчики считают что лучший интерфейс для работы с базами данных — текстовый интерфейс консольного. Я лично еще не достиг подобного просветления, поэтому больше доверяю GUI-инструментам. Хорошо, если у СУБД как у Postgres есть своя, утилита для работы с БД, а что делать если нет? Или если надо работать с различными базами данных одновременно? Под Windows альтернативных клиентов к различным СУБД — море разливанное. С другими ОС (я в данный момент работаю в OS X) все не так радужно, хотя есть программы разной степени пригодности и удобства. Раньше я использовал Navicat, но недавно нашел еще одно интересное решение, о котором и хочу рассказать: Valentina Studio.

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

Так как карьера программиста тесно связана с процессором, неплохо бы знать как он работает.

Что происходит внутри процессора? Сколько времени уходит на исполнение одной инструкции? Что значит, когда новый процессор имеет 12, или 18, или даже 31-уровневый конвейер?

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

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

Эта статья рассказывает, как устроен вычислительный конвейер x86 процессора.

Одной строкой: тут рекламируется Папирия, онлайновый сервис для подготовки документов в LaTeX. Ходить на papeeria.com.

Введение

Если вы студент, то наверняка либо уже пишете курсовую или диплом, либо всерьез над этим задумываетесь. Если вы к тому же учитесь в техническом вузе и в вашей работе много формул и прочего нетекста, то возможно, вы задумываетесь над тем, в чём его писать — в LibreOffice/Word или в LaTeX. И возможно, от использования LaTeX вас останавливает только то, что Word вот он, под рукой, бери и пиши, а латех надо еще устанавливать, возиться с почти неизбежными подводными камнями и потом еще тупо глядеть на белый лист и думать с чего начать. Вот вам-то мы и хотим помочь. А также тем, кто хочет вести свою научную работу из любого места, где есть интернет.

Для всех остальных: если вы вообще не знаете, что такое латех, то рекомендуем погуглить (можно начать, например, отсюда). Если же что-то знаете и просто хотите потроллить на тему latex vs word, то поищите себе, пожалуйста, другую поляну. Будем премного благодарны.

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

Суть сводится к тому, что эту команду в виде «make install» или «sudo make install» использовать в современных дистрибутивах нельзя.

Но ведь авторы программ в руководствах по установке пишут, что нужно использовать эту команду, возможно, скажете вы. Да, пишут. Но это лишь означает, что они не знают, какой у вас дистрибутив, и дистрибутив ли это вообще, может, вы вступили в секту и обкурилисьчитались LFS и теперь решили под свою хтоническую систему скомпилять их творение. А make install является универсальным, хоть и зачастую неправильным способом это сделать.

На момент написания этой статьи в JavaScript еще не существовало официальной модульной системы и все эмулировали модули как могли.

Модули или подобные структуры это неотъемлемая часть любого взрослого языка программирования. Просто иначе никак. Модули позволяют ограничить область видимости, позволяют реиспользовать части приложения, делают приложение более структурированным, отделяют ресурсы от шума и вообще делают код нагляднее.

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

Дело в том, что раньше не думали, что на JavaScript можно делать огромные проекты, а не просто «пропатчить DOM», поэтому о модулях не думали. Да и вообще не думали о будущем. И тут Внезапно будущее нагрянуло! Все вроде-бы уже есть, а модули в JavaScript, мягко говоря, запаздывают. Поэтому разработчикам приходится крутиться и выдумывать какие-то эмуляторы модульности.

Думаю многие из вас читали прекрасную статью Addy Osmani Writing Modular JavaScript With AMD, CommonJS & ES Harmony, которая стала одной из глав его книги Learning JavaScript Design Patterns в этой статье рассказывается про «современные» JavaScript модули или же читали достаточно старую статью JavaScript Module Pattern: In-Depth 2010 года про «старые» модули.

Я не буду переводить эти статьи и не буду делать из них солянку. В своей статья я хочу рассказать о моем модульном пути. О том как я проделал путь от «старых» модулей к «новым» и что использую сейчас и почему.

Не так давно, разрабатывая очередной программный продукт, наша команда разработчиков столкнулись с задачей реализации полноценной системы синхронизации пользовательских данных в реальном времени, путем рассылки (PUSH метод) изменений сервером. В самом приложении объем данных был не велик, но они могли просматриваться несколькими пользователями одновременно. Поэтому нам был необходим легковесный и достаточно производительный подход к синхронизации данных в рамках Веб-приложения. После того как были рассмотрены различные пути к решению этой задачи, мы остановили свой выбор на достаточно популярном эмуляторе WebSocket’ов – SockJS, который использует различные алгоритмы обмена данными между клиентом и сервером, в зависимости от браузера, которым пользуется клиент. В рамках данной статьи я не буду заострять внимание на том, почему был сделан именно такой выбор (по этому поводу написано немало статей, в том числе и на хабрахабре), а просто скажу, что мы ещё ни разу об этом не пожалели.

Изначально при изучении стандартных подходов к реализации подобного рода задач мы столкнулись с одной проблемой. Эта проблема заключалась в том, что взаимодействие с нашей системой производилось не только посредством веб интерфейса, но также посредством использования API сторонними продуктами, которые мы не могли контролировать. И конечный пользователь нашего продукта, безусловно, ожидает увидеть всю информацию об изменениях в данных, которые его касаются. Стандартный подход использования sockjs сервера подразумевает, что уведомления об изменении каких-либо данных в системе будут посылаться с использованием того же самого JS клиента, который используется для получения информации об этих изменениях. Именно поэтому в нашем случае такой подход был бы неприменим.

В этой статье я хотел бы рассказать о том, как мы решили эту задачу.

По мотивам одного вчерашнего поста про оптимизацию условных переходов при расчете x=sign(a,b)*min(abs(a), abs(b)) якобы в 10 раз. Краткая сводка:

• оптимизация налицо, но размер мнимый: не в 10 раз, а 2.5 раза;
• бенчмарки надо делать правильно: не надо мерить CPU stalls, RAM bandwidth итп вместо исследуемой функции;
• бенчмарки надо делать правильно: иначе могут дико дрожать;
• выставлять только приоритет прикольно, но на коротких бенчмарках зря: +0.5% скорости, -15% дрожания;
• нужно мерить исследуемую функцию и только ее, только так получаешь корректные данные;
• нужно греть проц, нужно считать минимум из N прогонов/секунд, только так побеждаешь дрожание;
• нужно пользовать SSE, с ним получилось 8.6 раз, причем код… читается.

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