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

Первая статья цикла посвящена распространённой проблеме Node.js — утечкам памяти, особенностям утечек в высоконагруженных проектах и библиотеке node-memwatch, которая помогает найти и устранить такие утечки в Node.

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

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"

---

Зачем заморачиваться?

Вы можете спросить, зачем вообще отслеживать утечки памяти? Неужели нет более важных дел? Почему бы просто не перезапускать процесс время от времени, или просто добавить памяти на сервер? Есть три причины, по которым устранять утечки всё-таки важно:

1. Возможно, вы не сильно переживаете об утечках памяти, но этого нельзя сказать о V8 (движок JavaScript на котором работает Node). Чем больше памяти занято, тем активнее работает сборщик мусора, замедляя ваше приложение. Так что в Node утечки напрямую вредят производительности.
2. Утечки могут привести к другим проблемам. Протекающий код может блокировать ограниченные ресурсы. У вас могут закончиться файловые дескрипторы или вы вдруг не сможете открыть ещё одно соединение с БД. Такие проблемы могут возникнуть задолго до того, как кончится память, но обрушат ваше приложение ничуть не хуже.
3. Рано или поздно ваше приложение упадёт. И это наверняка случится во время наплыва посетителей. Вас все засмеют и будут писать про вас гадости на Hacker News.

Доброго времени суток, уважаемые хабравчане. За последнее время я увидел несколько интересных и полезных инструментов/библиотек/событий, которыми хочу поделиться с Хабром.

Pace.js — это самый простой способ (документация здесь) добавить к вашему проекту прогресс бар. Для Pace существует несколько тем, которые описываются только на CSS. От Hubspot есть еще два универсальных проекта на GitHub: Vex и Messenger — «Dialogs for the 21st century» и «Alerts for the 21st century» соответственно. Рекомендую.

Flat UI Free 2.1
Популярный информационный ресурс Designmodo опубликовал на GitHub обширный набор элементов интерфейса в стилей трендового плоского дизайна. Об этом еще в марте писал хабраюзер ilya42. А на этой недели проект обновился до версии 2.1. Теперь в Flat UI есть поддержка Bootstrap 3, появился ряд новых элементов, иконок, обновилились шрифты. Количество старов уже больше 5000.

Framer
Потрясающее изобретение разработчика Koen Bok. Framer — это бесплатный инструмент для прототипирования интерактивных и анимационных интерфейсов. Приложение синхронизируется с Photoshop, нарезает слои макета на .png (конечно же для верстки придется немного порезать руками, но все зависит от педантичности дизайнера к макету) и все верстает на z-index и trasnform matrix3d. А интерактив и анимацию дизайнеры добавят с помощью этого простого синтаксиса прямо в браузере (к сожалению только Chrome). PSD.Logo, PSD.OverviewButton — это имена PNG файлов. Говоря о разработчике Framer, хочется также упомянуть про его проект Cactus — генератор статистических сайтов на Python использующий Django template.

Так получилось, что последние несколько недель очень часто приходилось слышать слова Promise и Deferred от разных людей. Как правило, этими понятиями оперируют уже повидавшие виды разработчики, столкнувшиеся в своей деятельности с определенными задачами.

Как я могу судить, для людей, которые на практике не столкнулись с некоторыми специфическими проблемами, эти 2 понятия являются довольно трудными для понимания. И не потому, что понятия Promise и Deferred являются с чем-то сложным, а потому, что довольно непросто сходу выдумать подходящую задачу, чтобы попробовать Deferred objects (в JQuery и не только) в действии.

Да, вероятно для тех, кто знаком с этим вопросом он покажется пустяковым и не стоящим и выеденного яйца. Кроме того, вопрос уже многократно обсуждался. Однако, я наберусь смелости еще раз его затронуть и вот почему: 1) Мне кажется, что для некоторых читателей этот пост может оказаться интересным. 2) Я пойду от практики, а не от теории. Моя задача — продемонстрировать работу инструмента. Теорию и другие варианты применения при необходимости вы найдете в ссылках к посту.

Ниже я попробую показать вам что Promise и Deferred это очень и очень просто. Кроме того, для объяснения этой темы, мне придётся затронуть еще несколько интересных моментов JavaScript.

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

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

Ну а чтобы не быть голословным — перейдём к примерам. Нас ждут:

1. Неудаляемые модели, которые мы удалим
2. Валидируемые поля, которые не валидируются
3. Два админа, которые портят данные

Mozilla Labs выпустила открытую библиотеку TogetherJS, с помощью которой на сайт легко добавить возможность коллективной работы в реальном времени.

Библиотека написана на JavaScript, не требует от посетителей установки никаких плагинов или программного обеспечения, всё работает сразу в браузере.

Для установки достаточно скопировать и вставить библиотеку и HTML-сниппет. TogetherJS дружественна к существующей структуре сайтов: скрипт ничего не меняет на сайте, только добавляет небольшую кнопку . По нажатию открывается дополнительное меню и появляется уникальная ссылка для отправки коллегам. Каждый, кто откроет эту ссылку, присоединится к групповой работе над данным документом.

После просмотра курса Programming Languages и прочтения Functional JavaScript захотелось повторить все эти крутые штуки в python. Часть вещей получилось сделать красиво и легко, остальное вышло страшным и непригодным для использования.

Статья включает в себя:

• немного непонятных слов;
• каррирование;
• pattern matching;
• рекурсия (включая хвостовую).

Статья рассчитана на python 3.3+.

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

Мы выступили с рассказом о том, как быстро запустить сложный проект, перспективы которого можно оценить только по реакции публики. Мы сторонники реального фидбека, а не экспертных заключений. Доклад был посвящен тому, как весной 2012 года запускался sociate.ru — проект для автоматизированного размещения рекламных сообщений в сообществах ВКонтакте.

Многое из того, что написано ниже, можно смело вложить в уста Капитана. Да, это действительно так. Но! Я сам из технарей и сам знаю, как часто мы увлекаемся какой-то технической фитюлькой, крутым рефакторингом или внедрением новых технологий. В 90% случаев пользователь об этом не узнает, особенно, если проект новый.

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

* еще раз, чтобы не было войны в комментариях — подход, описанный в статье подходит не всегда и не для всех проектов

Главной новостью этой недели, безусловно, стала презентация Apple новых смартфонов iPhone 5S/C и iOS 7, которые должны выйти уже в среду. Кроме того мы узнали, что АНБ может получить доступ практически к любому смартфону, Microsoft предлагает обменять iPad на подарочные карты для своих магазинов, VisionMobile снова посчитала роли в мировой экономики приложений, а Couchbase выпустила NoSQL-базу для iOS и Android.

Доброго времени суток, уважаемые хабравчане. С прошедшим вас днем программиста. За последнее время я увидел несколько интересных и полезных инструментов/библиотек/событий, которыми хочу поделиться с Хабром.

Cloudconvert

Великолепный онлайн конвертер файлов, который поддерживает в общей сложности 140 форматов следующих типов: archive, audio, cad, document, ebook, image, presentation, spreadsheet, video. Синхронизируется с Dropbox и Google Drive, благодаря чему возможно использование на всех смартфонах. А самое приятное это то, что для данного сервиса существует функциональное и простое API.

В последнее время все больше говорят про «NoSQL» — прямо «модный» тренд образовался. «Технологию» начинают активно использовать известные авторитетные компании, в т.ч. в высоконагруженных проектах с немалыми объемами данных — и кто-то восхищается, а кто-то обливает себя бензином и факелом выпрыгивает с 35 этажа с криком: "SQL ACID forever!"


Причем о каком бы продукте не говорили, будь то MongoDB или Cassandra — нередко приходится наблюдать прямо таки религиозную восторженность и трепет, как будто речь идет о чем-то новом и священном.

Я, к сожалению, не нашел русского перевода этого текста, хотя мне он показался крайне… просветляющим, что ли.

Признак 1: мы не используем sudo

Как CAPS LOCK — «круиз-контроль для крутотенюшки», так и sudo — «костыль для сомневающихся». Если нам нужно сделать что-то от имени root, мы используем su, а не фигню навроде sudo. Если какая-то из Unix-подобных операционных систем заставляет нас использовать sudo, то первое что мы делаем — sudo su и устанавливаем пароль для пользователя root, чтобы комфортно пользоваться su в дальнейшем. Постоянное использование sudo можно сравнить с плаванием c надувным кругом в животе — это безопаснее, да, но лишает необходимости обдумывания поступков.

Возможности встроенного в браузер инструмента Chrome Developer Tools можно расширить с помощью сниппетов. Это ускоряет разработку и упрощает рабочий процесс. Хорошая коллекция сниппетов есть на GitHub'е.

Сниппеты в Google Chrome

Подробно о функциях сниппетов можно почитать в официальной документации Chrome. А вот краткая инструкция:

1. Зайти в «chrome://flags» — Отметить «Enable Developer Tools experiments».
2. Открыть DevTools: «Settings» — «Developer Tools Experiments» — Отметить «Snippets support».
3. После перезагрузки во вкладке DevTools «Sources» появится «Snippets», где можно управлять сниппетами:

Только ленивый ещё не писал о необходимости писать тесты. Но давайте признаемся честно — писать тесты зачастую скучно. Особенно для legacy-кода. Сотни повторяющихся, однообразных строк. Скука. Что с этим можно сделать?


^{Картинка для привлечения внимания. Красивый питон, да? (Автор фото: Paweł Stefaniak)}

Спасибо Хабру, много полезного тут для себя нашел. Думаю, пора «отдавать долги».
Хочу описать алгоритм, который работает больше года на моем шлюзе для балансировки каналов (Гбит трафика, 8k клиентов, 2 провайдера, AS на 1k адресов, большинство клиентов за NAT). Возможно, кому-то пригодится. Во всяком случае, ничего похожего не встречал и когда специально искал — не нашел. Так что полностью мое детище.
Все, что попадалось на просторах Интернета, позволяло резервировать один из каналов. И исходящий регулировать — описаний много. А вот регулировать входящий трафик (т.е. обеспечить равномерную загрузку нескольких каналов) — не попадалось.
Конечно, указанный алгоритм нельзя считать универсальным, подойдет только в подходящих условиях.

Итак, исходные:
— Шлюз на Linux (Debian 6). Используется пакет quagga (бывший zebra).
— Два провайдера (пусть будут ТТК и РТК). Каждый дает канал определенной толщины, «лишнее» режет.
— AS на 1k адресов (пусть будет 1.1.144.0/22). AS0000.
— Большинство клиентов имеют серые адреса (пусть будет 192.168.0.0/16), «клиентские» сети 192.168.1-99.0/24, на шлюзе натятся.
— Небольшая часть клиентов имеют белые адреса в пространстве моей AS.

Задача:
Обеспечить равномерную загрузку каналов ТТК и РТК входящим трафиком для исключения перегрузки каналов.

Я был крайне удивлён, найдя мало статей про динамическое программирование (далее просто динамика) на хабре. Мне всегда казалось, что эта парадигма довольно сильно распространена, в том числе и за пределами олимпиад по программированию. Поэтому я постараюсь закрыть этот пробел своей статьёй.

# Весь код в статье написан на языке Python

Основы

Пожалуй, лучшее описание динамики в одно предложение, которое я когда либо слышал:

Динамическое программирование — это когда у нас есть задача, которую непонятно как решать, и мы разбиваем ее на меньшие задачи, которые тоже непонятно как решать. (с) А. Кумок.

1. Введение
2. Объекты. Голова
3. Объекты. Хвост
4. Структуры процесса

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

В предыдущих частях мы говорили об объектной системе Питона. Тема ещё не исчерпана, но давайте пойдём дальше.

Когда я размышляю о реализации Питона, я представляю себе огромный конвейер, по которому движутся коды машинных операций, которые затем попадают в гигантский завод, где повсюду возвышаются градирни и башенные краны, — и меня просто переполняет желание подойти поближе. В этой части мы поговорим о структурах состояния интерпретатора и состояния потока (./Python/pystate.c). Сейчас нам нужно заложить фундамент, чтобы потом было легче понять, как исполняется байткод. Совсем скоро мы узнаем, как устроены фреймы, пространства имён и объекты кода. Но для начала давайте поговорим о тех структурах данных, которые связывают всё воедино. Учтите, я предполагаю наличие хотя бы поверхностного понимания устройства операционных систем и знания хотя бы таких терминов, как ядро, процесс, поток и т. п.

Во многих операционных системах пользовательский код исполняется в потоках, которые живут в процессах (это верно для большинства *nix-систем и для «современных» версий Windows). Ядро ответственно за подготовку и удаление процессов и потоков, а также за определение того, какой поток на каком логическом CPU будет исполняться. Когда процесс вызывает функцию Py_Initialize, на сцену выходит другая абстракция, интерпретатор. Любой Python-код, запускаемый в процессе, привязан к интерпретатору. Об интерпретаторе можно думать как об основе всех прочих концепций, которые мы будем обсуждать. Питон поддерживает инициализацию двух (и более) интерпретаторов в одном процессе. Несмотря на то, что эта возможность редко используется на практике, я буду её учитывать. Как было сказано, код исполняется в потоке (или потоках). Не исключение и виртуальная машина Питона (VM). При этом сама VM имеет поддержку потоков, т.е. у Питона есть своя абстракция для представления потоков. Реализация этой абстракции полностью полагается на механизмы ядра. Таким образом, и ядро, и Питон имеют представление о каждом из Python-потоков. Эти потоки управляются ядром и исполняются как отдельные потоки параллельно всем прочим потокам в системе. Ну… почти параллельно.

До сих пор мы не обращали внимания на слона в нашей посудной лавке.

Работая в очередной раз с модулем cluster, я столкнулся с необходимостью обмена сообщениями между рабочими процессами. К сожалению стандартный функционал модуля позволяет отправлять сообщения только с master процесса на worker, и в обратном направлении. При этом нет возможности получить какой-то ответ на сообщение, а очень хотелось бы. Поэтому я написал модуль cluster-hub. Возможно кому-нибудь он пригодится.

Модуль позволяет

• Отправлять сообщения master->worker, worker->master, master->master
• Отправлять запросы и получать ответы (через callback)
• Использовать эксклюзивные блокировки по ключу (критические секции)

Кому интересно — прошу под кат.

1. Введение
2. Объекты. Голова
3. Объекты. Хвост
4. Структуры процесса

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

Как я и писал в предыдущем эпизоде (который, кстати, оказался успешным; спасибо всем, ваши просмотры и комментарии буквально заставляют меня двигаться дальше!) – сегодняшний пост посвящён реализации объектов в Python 3.x. Поначалу я думал, что это простая тема. Но даже когда я прочитал весь код, который нужно было прочитать перед тем, как написать пост, я с трудом могу сказать, что объектная система Питона… гхм, «простая» (и точно не могу сказать, что до конца разобрался в ней). Но я ещё больше убедился, что реализация объектов — хорошая тема для начала. В следующих постах мы увидим, насколько она важна. В то же время, я подозреваю, мало кто, даже среди ветеранов Питона, в полной мере в ней разбирается. Объекты слабо связаны со всем остальным Питоном (при написании поста я мало заглядывал в ./Python и больше изучал ./Objects и ./Include). Мне показалось проще рассматривать реализацию объектов так, будто она вообще не связана со всем остальным. Так, будто это универсальный API на языке C для создания объектных подсистем. Возможно, вам тоже будет проще мыслить таким образом: запомните, всё это всего лишь набор структур и функций для управления этими структурами.

Коллеги, использующие Backbone.js! Вы задумывались, как работает наследование в этой библиотеке?
Знаете, как себя ведет Backbone.Model.extend({})?
И наверняка знаете и помните, что у extend два опциональных параметра: proto props и static props.
Если хотя бы на один выше заданный вопрос вы ответили отрицательно — прошу под кат.
Постараюсь порадовать пошаговым исследованием, схемками, табличками и примерами.

JavaScript, the winning style

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

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

В отличие от Питона у которого есть единый свод правил «Style Guide for Python Code», у языка JavaScript такого нет. Однако на выбор есть целых 6 популярных гайдов:

• Google JavaScript Style Guide
• npm’s coding style
• Felix’s Node.js Style Guide
• Idiomatic JavaScript
• jQuery JavaScript Style Guide
• Douglas Crockford’s JavaScript coding style

Помимо гайдов, не стоит так же забывать об автоматических анализаторах кода, таких, например, как JSLint и JSHint. И в них уже заложены свои настройки. Вопрос в том, какой же все-таки максимально правильный способ писать код на JavaScript, который был бы актуален и максимально соответствовал бы большинству рекомендаций? Давайте попробуем объединить большинство рекомендаций в этой статье и подумаем как можно оптимизировать процесс проверки качества кода.