Добрый день, уважаемые читатели.

В последнее время на Хабре всё чаще упоминается такой замечательный фреймворк, как React.js. Я работаю с ним уже 4 месяца, поэтому решил поделиться опытом использования. Решено было сделать небольшую серию статей, которые должны стать максимально кратким полным руководством по фреймворку. Это моя первая публикация на Хабре, поэтому прошу не судить слишком строго. Моя главная задача – рассказать о подходах и практиках, второстепенная – узнать у людей, использовавших React, как они работают с ним и как они решали те или иные кейсы. Ну и, конечно, расширить сообщество фреймворка. Начало я оформил в виде небольшого конспекта-шпаргалки. А дальше только практика.

Сегодня в рамках наших уроков английского мы расскажем об английских идиомах с именами.

John

John – одно из самых распространённых английских имён. Наверное, именно поэтому оно породило так много интересных идиом, а вымышленные и вполне себе реальные Джоны превратились в нарицательных персонажей:

John Q. Public или John Q. Citizen (товарищ или гражданин Джон Кью) – американизм, обозначающий среднестатистического гражданина, обычного человека. К слову, среднестатистическую гражданку называют Jane Q. Public.

John Hancock (Джон Хэнкок) – имя этого американского государственного деятеля, чья размашистая подпись под Декларацией независимости США приобрела всеобщую известность, стало нарицательным и используется для обозначения вообще всякой подписи. У нас шутливо говорят «поставить закорючку», а американцы просят «поставить своего джона хэнкока», тоже в шутку, разумеется.

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

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

Меня заинтересовал вопрос номер 3:
Каков результат этого выражения (или нескольких)?

[ [3,2,1].reduce(Math.pow), [].reduce(Math.pow) ]

В качестве ответа авторами, на выбор, даются следующие варианты:
* ошибка
* [9, 0]
* [9, NaN]
* [9, undefined]

Попробуйте и вы, без запуска интерпретатора, пользуясь только своим умом ответить на этот вопрос.

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

А в этой статье вы найдёте:
* Разбор задачки.
* JavaScript reduce с чисто практической точки зрения.
* Несколько акробатических этюдов с reduce (reduce с академической точки зрения).
* Репозиторий с плюшками к статье.
* Несколько других reduce.

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

Стоит вспомнить, что эти принципы (в продолжении они все показаны) созданы группой аниматоров, ставших основой Disney. Эта группа даже получила название "9 стариков Диснея".

Эти приемы были описаны во внутреннем проекте компании Google «Testing on the Toilet» (Тестируем в туалете — распространение листовок в туалетах, что бы напоминать разработчикам о тестах).
В данной статье они были пересмотрены и дополнены.

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

Быстрое изменение состояния посреди анимации

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

@keyframes toggleOpacity {
  50% { opacity: 1; } /* Turn off */
  50.001% { opacity: 0.4; }

  /* Keep off state for a short period */

  52.999% { opacity: 0.4; } /* Turn back on */
  53% { opacity: 1; }
}

Вот как я использовал этот приём для имитации мигающей неоновой вывески с помощью прозрачности и свойства text-shadow:

Компания Apple недавно допустила крупную ошибку, забыв удалить лишнюю строчку с оператором безусловного перехода goto посередине функции SSLVerifySignedServerKeyExchange для проверки серверной подписи при установке SSL-соединения. В результате, функция успешно завершала работу, независимо от результата проверки подписи.

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

X Server

В 2006 году было обнаружено, что X Server проверяет рутовые права у пользователя, но при этом разработчики в реальности забыли вызвать соответствующую функцию.

--- hw/xfree86/common/xf86Init.c
+++ hw/xfree86/common/xf86Init.c
@@ -1677,7 +1677,7 @@
   }
   if (!strcmp(argv[i], "-configure"))
   {
-    if (getuid() != 0 && geteuid == 0) {
+    if (getuid() != 0 && geteuid() == 0) {
        ErrorF("The '-configure' option can only be used by root.\n");
        exit(1);
     }

Предисловие

Уже около четырех лет увлекаюсь языком JS, а особенно привлекает в нем прототипная реализации объектной ориентации и замыкания. Так как я большой любитель «велотренажеров» в программировании и обожаю изучать что-то новое на практических примерах, давно хотел попробовать реализовать подобное самостоятельно, и совсем недавно шанс выпал. Одним холодным зимним днем я увлекся редактором Vim и, изучая его скриптовый язык, обратил внимание на некоторые важные особенности, а именно ассоциативные массивы и передачу функций по ссылке. Я не смог пройти мимо и реализовал свою прототипную объектную ориентацию в Vim с наследованием и полиморфностью.

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

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



Сейчас мало кто помнит, что самая первая версия Яндекс.Почты была написана на PHP, а письма хранились прямо в реляционной БД рядом с мета-информацией. В том не таком уж и далёком 2000 году весь почтовый сервис умещался на десятке серверов. Сами сервера обслуживались полностью в ручном режиме: от конфигурации дисков до установки операционной системы, никакой автоматизации не было.

Этот текст является переводом статьи 'Stop Being Cute and Clever' небезызвестного (по крайней мере, в Python-комьюнити) Армина Ронахера.

Последние дни в свободное время я занимался созданием планировщика. Идея была простой: создать некий клон worldtime buddy c использованием AngularJS и некоторых других JavaScript-библиотек.

И знаете что? Это было отнюдь не весело. Я уже давно так сильно не злился, работая над чем-либо, а это что-то значит, потому что обычно я быстро высказываю своё недовольство (прошу прощения у моих фолловеров в Twitter).

Я регулярно использую JavaScript, но мне редко приходилось сталкиваться с кодом других людей. Обычно я привязан только к jQuery, underscore и иногда AngularJS. Однако в этот раз я пошел ва-банк и решил использовать различные сторонние библиотеки.

Для данного проекта я использовал jQuery, без которого уже нельзя обойтись (да и зачем?), и AngularJS с некоторыми UI-компонентами (angular-ui и биндинги к jQuery UI). Для работы с часовыми поясами использовался moment.js.

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

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

Последние 3 или даже 4 месяца я долго и упорно писал IDE/редактор кода для веб-программистов под Android. Так получилось, что 2.5 года назад я уже писал в паре с товарищем аналогичную программу, и каким-то чудом она была достаточно успешной, несмотря на то, что это был практически первый опыт создания чего-либо, кроме университетских лабораторных работ.

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

Любопытный пример минимализма продемонстрировал пользователь GitHub c ником Aemkei.

На скриншоте — известная игра Тетрис, справа — её исходный код. В игре нельзя вращать фигуры, нет подсчета очков — зато она может похвастаться размером JS-кода: менее 140 байт.

Поиграть можно здесь.

Github автора c его комментариями.

UPD: Судя по всему, автор — Мартин Клеппе — занят любимым делом: у него также есть реализации игры «Жизнь» на JavaScript (140 байт) и на Ruby (140 символов).

В булевой алгебре, используемой для моделирования работы цифровых схем, не учитывается время перехода (или инертность) логических элементов (например, «И», «ИЛИ») из одного состояния в другое (например, из 0 в 1). В случаях, когда время распространения сигнала внутри элемента достаточно мало, задержку перехода можно не учитывать. Но с повышением частоты изменения входных сигналов в реальных схемах начинает сказываться влияние времени распространения сигнала внутри ее элементов. Такие задержки могут порождать неустойчивую работу устройств (т.е. в сигналах после последовательного прохождения через узлы схемы появляются не учитываемые моделью схемы переходы, называемые сбоями). Многие производители современных процессоров держат в тайне, как они борются со сбоями, порождаемыми задержками, на частотах порядка ГГц. Ведь обычный проводник с множеством близких изгибов на плате в таком режиме работы уже превращается в индуктивность.

Чтобы проанализировать простейшие схемы на риски сбоя, обычно применяют метод временных диаграмм, ставший уже классическим. Сигналы в каждом узле прочерчиваются строго друг под другом; где нужно, производится искусственная задержка перехода из одного состояния в другое, а далее по булевому представлению строятся выходные сигналы. Данный метод не хорош тем, что требует работы с графиками, что может внести погрешность в получаемые сигналы. А нам нужно знать, возникнет ли сбой, и какой он будет иметь вид.

В 2005-м году я касался этой темы и изложил свои мысли в данной заметке на английском языке. Однако мой хороший знакомый посоветовал написать в Хабрахабр для обсуждения с пользователями.

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

Начнем…

В 1975м году, ПК IBM 5100 выпускалась в вариантах с языками программирования BASIC или APL. Как можно догадаться, что в итоге основной упор был сделан на интерпретатор BASIC'а по причине того, что при принятии решения о том, что покупать, пользователям данного ПК он казался более понятным, а APL требовал какого-то минимального уровня вхождения. Говорят, что что APL потерял популярность из-за не ascii-символов, может это отчасти и так, но произошло это не в 75м.

Возможно, история программирования языков повернулась бы чуть иначе, если бы развитие пошло с упором на интерпретатор APL'а, но об этом остаётся только фантазировать, так что предлагаю просто понаблюдать за тем, как писали программы в далёком 1975м.

до 5й минуты простая математика.

Годами я использовал Chrome DevTools, Firebug и даже Opera Dragonfly для отладки, трасировки и профилирования моего JavaScript кода. Замечу, что использовал эти замечательные инструменты не только для работы с JavaScript, но и для отслеживания событий сети, отладки CSS, работы с DOM.

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

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

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

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

В рамках федеральной программы, инициированной указом президента РФ №597 от 7 мая 2012 г., ведётся разработка новых профессиональных стандартов в области ИТ. На днях опубликованы черновики профстандартов админа БД, программиста, руководителя проектов в области информационных технологий, руководителя разработки программного обеспечения и т.д.

11-13 сентября 2013 года пройдут открытые вебинары с подробным обсуждением первой версии каждого из разрабатываемых профессиональных стандартов.

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

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

'hello, %(thing)s' % {'thing': 'world'}

Или вот так:

'hello, {thing}'.format(**{'thing': 'world'})

От переводчика:
Я собрался изучить новый для меня паттерн Стратегия, но не нашёл толкового русского описания его реализации на javascript. Статья на wiki пугает своей сложностью, а наглядность примера оставляет желать лучшего. По этому и взялся за перевод этой статьи, одновременно разбираясь, что же из себя представляет данный паттерн.
Спойлеры и текст, выделенный серым, являются моими комментариями.

Далее мы разберём примеры того, как я использую СТРАТЕГИЮ в Javascript, и как он используется реальной библиотекой, для разбиения её на небольшие части.