Перевод статьи Ричарда Корнфорда Javascript Closures.

• Введение
• Разрешение имен свойств объектов
  
  • Присваивание значений
  • Чтение значений
  
  
• Разрешение имен идентификаторов, контексты исполнения и цепь областей видимости
  
  • Контекст исполнения
  • Цепь областей видимости и свойство [[scope]]
  • Разрешение имен идентификаторов
  
  
• ...

Введение

Замыкание

Замыкание — это выражение (обычно функция), которое может иметь свободные переменные, вместе со средой, которая привязывает эти переменные (т.е. “замыкает” это выражение).

Замыкания относятся к наиболее мощным особенностям ECMAScript (javascript), но они не могут быть применены должным образом без понимания. Несмотря на то, что их легко создать, даже случайно, их создание может иметь пагубные последствия, в частности, в некоторых относительно распространенных окружениях браузеров. Чтобы избежать случайных столкновений с недостатками и использовать преимущества замыканий, необходимо понимать их механизм. Это сильно зависит от роли цепи областей видимости в разрешении имен идентификаторов (identifier resolution) и от разрешения имен свойств в объектах.

Самое простое объяснение замыкания в том, что ECMAScript допускает вложенные функции, определения функций и функции-выражения (function expressions) внутри тел других функций. И эти вложенные функции имеют доступ ко всем локальным переменным, параметрам и функциям, находящихся внутри их внешней функции (внешних функций). Замыкание образуется, когда одна из этих вложенных функций становится доступной вне той функции, в которую она была включена, таким образом, она может быть выполнена после завершения внешней функции. В этот момент она все еще имеет доступ к локальным переменным, параметрам и внутренним декларациям функций (function declarations) своей внешней функции. Эти локальные переменные, параметры и декларации функций (изначально) имеют те же значения, которые были во время завершения внешней функции и могут взаимодействовать с внутренней функцией.

К сожалению, правильное понимание замыканий требует понимания механизмов, которые стоят за ними, и немало технических подробностей. Хотя некоторые из алгоритмов, определенных в ECMA 262, затронуты в начале последующего объяснения, большинство не могут быть опущены или просто приведены к упрощенному виду. Если вы знакомы с разрешением имен свойств объектов, то можете пропустить этот раздел, но только люди, уже знакомые с замыканиями, могут позволить себе пропустить последующие разделы и прямо сейчас перестать читать и вернуться к их использованию.

Пост содержит перевод статьи «Error Handling in Node.js», которую подготовили сотрудники компании Joyent. Статья была опубликована 28 марта 2014 года на сайте компании. Dave Pacheco поясняет, что статья призвана устранить неурядицу среди разработчиков, касаемо лучших практик работы с ошибками в Node.js, а так же ответить на вопросы, которые часто возникают у начинающих разработчиков.

В данной статье я хотел бы поделиться собственным опытом создания компании, не обремененной месторасположением. Лично мы называем это организованный фриланс.

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

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

В-третьих, вся работа выполняется сдельно, существуют премии, бонусы, но не оклады, что заставляет участников команды быть заинтересованными в высоких результатах, в больших объемах работы.

В чем суть?

У меня нет обычного зомбо-телевидения — я не смотрю эфирные каналы уже лет 7, чему несказанно рад и вам советую. Для вечернего диванного времяпрепровождения после трудового дня дома имеется полный стек продуктов от яблочной компании — начиная с компьютера-лаптопа и заканчивая тв-приставкой (подключенной к обычному 34" телевизору по HDMI). Все это между собой прекрасно работает и дружит, а используя некоторые онлайн-сервисы я вообще могу смотреть любимые сериалы прямо из интернета и не качая торренты. Жилось-былось мне так вполне хорошо, но вот в России проводят Олимпиаду, а тут еще и тесть приехал — заядлый спортсмен. Хочется посмотреть Игры! И таким вот образом образовалась задача — обеспечить качественный показ спортивных передач (то есть не на экране мобильного телефона), которые идут на нескольких эфирных каналах и все это используя подручные средства. И чтобы не очень долго и сложно было реализовывать.

От переводчика: это перевод статьи Кристиана Глобмайера The Ten Rules of a Zen Programmer. Статья мне понравилась, решил сделать перевод, после окончания перевода загуглил название, нашел вариант перевода: 10 принципов дзен программиста. Отличается от моего, поэтому решил свой вариант перевода все-таки запостить.

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

Одним дождливым утром я сидел за своим столом и думал об эффективной работе. До того, как я начал работать фрилансером, у меня бывало, что я работал много, но никогда не был доволен результатом. Я начал практиковать Дзен в 2006 году. То, что мне пришло в голову через довольно большое время — старые мастера Дзен уже знали сотни лет назад, как сегодняшние программисты должны работать. Хотя я не люблю посты «как быть лучшим программистом», я хочу рассказать о некоторых моих мыслях с того времени. Этот пост будет служить мне напоминанием, но если у вас есть идеи, не стесняйтесь оставлять комментарии.

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

Думаю многие видели обзоры игровых консолей нового поколения от Polygon (Vox Media). Это те, где консоли отрисовывались в стиле blueprint'ов:


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

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

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

• BEM
• Собственно пример — как сверстать страницу

Сайтов с адаптивной разметкой с каждым месяцем становится все больше, заказчики кроме кроссбраузерности все чаще требуют адаптивность, но многие разработчики не спешат обучаться новым техникам. Но адаптивный дизайн — это просто! В этой статье представлено 5 примеров адаптивной разметки различных элементов веб-страниц.

У каждого из нас скопились десятки ненужных и сломанных гаджетов. Оказывается, все эти приборы способны принести немного пользы перед своим уничтожением.

Инженер и химик Джозеф Мурчинсон (Josehf Murchison) опубликовал на сайте Instructables пошаговую инструкцию, как выплавлять золото из старых электронных приборов, которые вы собирались выбросить на свалку: старые ноутбуки, телефоны, камеры, принтеры, сканеры и прочее ненужное барахло.

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

Практически пять лет назад я опубликовал на Хабре пост про свой типограф: habrahabr.ru/post/67010. Прошло много времени, он несколько раз обновлялся и получал продолжения в модулях для движков и блогов. Пришло время задуматься о самом лучшем и грамотном инструменте, который будет за вас типографировать текст. Именно по этому я вернулся к своему типографу и все начал заново.

Типограф — инструмент для форматирования текста с использованием норм, правил и специфики русского языка и экранной типографики.

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

О продукте

1. Типограф получил поддержку Unicode (это позволяет получать на выходе сразу красивый и форматированный текст без HTML-мнемоники). По умолчанию он отключен, нужно вручную включить.
2. Включил около 70 правил, 30 дополнений и исключений к ним. На сайте есть раздел со всеми общими правилами, там можно подробнее прочитать. Но опять-таки они не все, т.к. есть множество под-правил и условий.
3. Теперь типограф занимаем всего один файл (EMP.php) и доступен для PHP, но в ближайшее время выйдут версии и для Python (в процессе), Ruby, Perl и JS.
4. Инструмент бесплатный и всегда будет оставаться таким. Открытый исходный код. При использовании мы не просим ничего указывать, но будет здорово, если расскажете об этом.
5. Каждое правило можно включить или выключить. Внутри много скрытых правил.
6. Реализована висящая пунктуация (некоторые это называют оптическим выравниванием).

Вы PM. Как узнать – готова ли вёрстка к реальному использованию?
Вы заказчик. Как убедиться, что работа выполнена качественно?
Как оценить качество вёрстки?

Когда я стал тим-лидом, а позже PM, передо мной стала задача проверять вёрстку наших проектов. Нужно было выработать формальные, легкопроверяемые критерии, соответствие кода которым, должно было давать некую гарантию, что не будет факапов и ни клиент, ни программеры не сказажут потом “WTF?”.

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

Требования должны были быть такие, что соблюсти их легче, создавая качественную вёрстку, а не говнокод. Я составлял такой чек-лист в течении полутора лет. За последние полгода в него не добавилось ничего. Значит самое главное учтено.

Итак что же это за список?

Краткая версия теперь доступна на html5checklist.com (github), где можно вносить pull-request'ы.

История обновлений:

• 2015/08/11: Актуализировал рекомендации по оптимизации скорости загрузки. Добавил требование поддержки Retina. Дополнил «19. Мелочи» требованием что изображения должны масштабироваться в зависимости от размера окна.
• 2015/08/10: актуализирован список исключений для CSSLint
• 2015/07/29: актуализирован пункт №13 «плохо»/«хорошо»
• 2015/04/08: добавлено требование использования препроцессоров и рекомендация использования систем сборки
• 2013/04/25: добавлены анализаторами качества кода: CSSLint и JSHint, указан сайт подбора css font stack (спасибо @fliptheweb), мелкие уточнения (работу интерактивных элементов страницы, что не пропадает фон на высоких разрешениях, не должно быть пустых презентационных блоков, при проверках контента — пробовать удалять заголовки, менять местами блоки)
• 2013/04/24: добавил пункт об минимизации каскада (БЭМ-техники, MCSS, SMACSS), необходимости вписывания в экран моб. устройства, заменил ссылку на проверочный текст отображения стандартного html на код с normalize.css, поправил пример где в рекомендации встречался длинный каскад, упомянул про Opera на Presto и новый уровень семантики — в именах классов BEM.
• 2012/04/12: отсортировал пункты проверки в порядке важности, выделил главные, дополнил статью подробностями
• 2011/12/07: дополнил согласно доклада на WSD Минск'2011.
• 2011/07/19: добавлено про повышение надёжности вёрстки благодаря html5-тэгам, про необходимость favicon/apple-touch-icon, отсутствие багов при ресайзе textarea
• 2011/06/15: добавил пояснения какие ошибки валидации допустимы, рассказал про отсутствие официальной кнопки «HTML5 Valid» и про официальное лого HTML5 на сайте.

В данном посте я расскажу о наиболее интересных командах, которые могут быть очень полезны при работе в консоли. Однозначных критериев определения какая команда лучше другой — нет, каждый сам для своих условий выбирает лучшее. Я решил построить список команд на основе наиболее рейтинговых приемов работы с консолью от commandlinefu.com, кладовой консольных команд. Результат выполнения одной из таких команд под Linux приведен на картинке. Если заинтересовало, прошу под кат.

В марте 2012 года Гай Подъярны (Guy Podjarny) провел тест, в ходе которого сравнивалась продуктивность работы сотен новых адаптивных сайтов на устройствах с четырьмя различными разрешениями экранов. Получившиеся результаты были весьма разочаровывающими.

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

Возможности встроенного в браузер инструмента 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», где можно управлять сниппетами:

3. Прототипное наследование

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

Далее в игру вступает наследование. Оно лучше разделяет понятия, когда объекты наделяются своими методами на основе методов других объектов.

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

— Прототипное наследование — это прекрасно
JavaScript — это объектно-ориентированный (ОО) язык, уходящий корнями в язык Self, несмотря на то, что внешне он выглядит как Java. Это обстоятельство делает язык действительно мощным благодаря некоторым приятным особенностям.

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

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

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

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

Добавлено в 20:22
Сегодня ночью семья Ильи сообщила, что он скончался. Потом поступила информация, что Илья подключен к аппарату жизнеобеспечения, но признаков мозговой активности нет. Мы ждем официальную информацию.

Мы дружили с Илюшей со школы, четыре года сидели за одной партой. А потом вместе делали Яндекс. Сегодня ночью его не стало. Все случилось слишком быстро и неожиданно.

Последний раз он выступал перед нашими cтамбульскими ребятами в прошлый четверг. Он вышел и сказал: «Здравствуйте, меня зовут Илья». Все засмеялись, и он рассказал про поисковую платформу Острова.

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

Аркадий Волож