JavaScript *

Недавно я написал ряд заметок, так или иначе касавшихся работе с букмарклетами в браузерах, и почти в каждой упомянул о какой-то проблеме с IE, высказывая надежду, что придёт MS Edge и всё исправит.

Поэтому не смог пропустить появление виртуальных машин с Windows 10 и решил проверить, как теперь обстоят дела с коллекцией досадного опыта.

На машине оказалась версия MS Edge 11.00.10240.16397 от 7.22.2015 (по версии файла), она же 20.10240.16384.0 (по информации в настройках браузера)…

Предлагаем вашему вниманию подборку с ссылками на полезные ресурсы, интересные материалы и IT-новости

Началось все с того, что я оптимизировал отдачу ошибки HTTP 408 Request Timeout в сервере приложений Impress, работающем на Node.js. Как известно, у нодовского http.Server есть событие timeout, которое должно вызываться для каждого открытого сокета, если тот не закрылся за указанное время. Хочу уточнить, что не для каждого запроса т.е. не для каждого события request, функция которого имеет два аргумента (req, res), а именно для каждого сокета. Через один сокет может последовательно поступить много запросов в режиме keep-alive. Если мы задаем это событие, через server.setTimeout(2 * 60 * 1000, function(socket) {...}) то должны сами уничтожать сокет socket.destroy(). Но если не установить свой обработчик, то http.Server имеет встроенный, который уничтожит сокет через 2 минуты автоматически. На этом самом таймауте можно отдать ошибку 408 и считать инцидент исчерпанным. Если бы не одно но… С удивлением я обнаружил, что событие timeout вызывается и для тех сокетов, которые подвисли и для уже получивших ответ и для закрытых клиентской стороной, вообще для всех, находящихся в режиме keep-alive. Это странное поведение оказалось достаточно сложным, и я расскажу об этом ниже. Можно было бы вставить одну проверку в событие timeout, но со своим идеализмом я не удержался и полез исправлять баг на уровень глубже. Оказалось, что в http.Server режим keep-alive реализован не то что не по RFC, а откровенно не дописан. Вместо отдельного timeout для соединения и отдельного keep-alive timeout, там все на одном таймауте, который реализован на быстрых псевдо-таймерах (enroll/unenroll), но задан по умолчанию в 2 минуты. Это было бы не так страшно, если бы браузеры хорошо работали с keep-alive и переиспользовали его эффективно или закрывали бы неиспользуемые соединения.

Предлагаем вашему вниманию подборку с ссылками на полезные ресурсы, интересные материалы и IT-новости

Осталось совсем немного до окончания набора в третью Школу разработчиков интерфейсов, которая в этот раз пройдёт в Москве. Упор в ней будет сделан на практику в формате виде мини-хакатонов. Его мы уже опробовали в прошлом году в Минске и Екатеринбурге. Студенты будут делиться на команды, и уже командно реализовывать проект. Кроме написания самого кода, нужно будет уметь принимать решения, разбираться с возникшими спорными вопросами, разбивать весь процесс разработки на логические итерации. Помогать в этом будут ребята из Яндекса, которые будут работать индивидуально с каждой командой. Занятия начнутся 7 сентября.

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

Вступительное испытание в Школу тоже очень практическое. Мы закончим принимать заявки 16 августа в 23:59. Пока есть еще время справиться с заданиями, мы попросили наших преподавателей немного помочь будущим студентам и на примере прошлогодней анкеты объяснить, какой логикой стоит руководствоваться, решая предложенные задачи, и рассказать, чему они уделяют внимание при их проверке.



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

Доброе время суток хабравчане! Буквально на днях я опубликовал статью по документации Web API и нашлись люди, которые попробовали применить XSS на сервисе, который был на этом же домене. Но особо не получилось это сделать. Точнее получилось, но не на этом сервисе. За подробностями прошу под кат.

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

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

Несмотря на номер версии 3.0, мы ожидаем, что этот выпуск не доставит слишком много неприятностей при модернизации кода. Да, есть несколько критичных изменений, что оправдано сменой старшего индекса версии, но, надеемся, что эти переделки не повлияют на многих. Плагин jQuery Migrate поможет выявить проблемы совместимости кода. Также, ваши мнения об этой альфе нам сильно помогут, поэтому, пожалуйста, попробуйте её на существующем коде и плагинах!

Первый из релизов, jQuery 3.0, поддерживается новыми браузерами и IE 9+. Второй, jQuery Compat 3.0, поддерживается в IE 8+. Как бонус, оба релиза будут поддерживаться Яндекс-браузером, выпущенным в 2012-м.

Не так давно я написал топик про Билайн и их автоматическое добавление тулбара с поиском mail.ru. Тогда в html код добавлялся java-script файл, который в свою очередь добавлял плашку с реферальным поиском mail.ru. Прошло 2 месяца и Билайн решил делать все по-другому.

Вчера, просматривая сайты через мобильный интернет, я увидел, что на них стал отображаться обновленный тулбар от Билайн. Как его отключить было непонятно: кнопки закрытия не было, можно было только убрать его наверх, но все равно он виднелся на экране. Пришлось принять соглашение на продажу своих органов и только после этого появилась волшебная кнопка «Удалить тулбар навсегда».

Я подумал, что на этом все закончилось, но как оказалось — я ошибся.

Предлагаем вашему вниманию подборку с ссылками на полезные ресурсы, интересные материалы и IT-новости

За последние несколько месяцев я сделал несколько доработок для JSHint, в основном с целью изучить ES6 (я особенно горжусь тем, как переделано обнаружение областей видимости для переменных). Во время этого процесса я наткнулся на несколько вещей, которые меня удивили — в основном, в ES6, однако есть и кое-что про ES3, что я до этого никогда не использовал.

Break из любого блока

Наверняка вы знаете, что в любом цикле можно использовать ключевые слова break и continue — это стандартная возможность в современных языках программирования. Однако не все знают, что циклам можно давать метки и с их помощью прерывать любой конкретный цикл:

outer: for(var i = 0; i < 4; i++) {
    while(true) {
        continue outer;
    }
}

Я должен признаться, что написать эту статью я решил очень спонтанно, прочитав статью «XMPP отстой» и почувствовав некоторую близость к чувствам автора, так как также использую ХМРР в одном из наших продуктов. Тем не менее, сжав эмоции в кулак, я всё-таки решил просто изложить, почему я испытываю смешанные чувства к данному протоколу и разложить по полкам плюсы и минусы. Также расскажу, что мы выбрали для сервера и клиента. Это все, чтобы тебе, дорогой читатель, сделать правильный выбор и вырвать меньше волос в твоих будущих проектах.

Веб ожидает большое будущее.

Вчера Брендан Айк “взорвал” сообщество веб-разработки: веб получит новый низкоуровневый бинарный компилируемый формат, который будет работать гораздо лучше, чем JavaScript.

Google, Microsoft, Mozilla, а также несколько независимых специалистов работают над новым проектом в W3C WebAssembly Community Group, и то, над чем они работают, совсем не маленькая вещь.

В то время пока я собирался на ланч, мой ко-воркер Дейв окликнул меня: «Хэй, Алекс, а ты не хочешь заниматься улучшениями навыков своего программирования?». Я задумался. Это было интересное предложение, но я склонялся ответить отказом: «Сейчас я занимаюсь развитем навыков говорения на языках, дружище!». Ладно, шучу. Утро началось с того, что я добрался до почты и заполучил в руки копеечный китайский Кубик, случайно заказанный на али. К обеду я проштудировал мануал сборки и обновил мышечную память, а к вечеру пришло осознание, что я наигрался. Будущее кубика было ясным: он будет пылиться на полке, раз или два в неделю может быть я буду его собирать, чтобы привести мысли в порядок или отвлечься, но не более того. Соревнование в механической скорости сборки? Non merci, уж лучше скворечники делать…

Ситуацию, как всегда, спасли мысли об автоматизации. После недолгого изучения я узнал рекогнисцировку. Для начала, число Бога уже давно найдено и равно 20. Правда задача сборки от этого не упрощается, т.к. использовать граф кратчайших путей для всех возможных конфигураций кубика не очень спортивно и немножко накладно по ресурсам. Алгоритм Бога предполагает под собой некое разумное количество использованной памяти, и в то же время обязан обеспечить минимально возможное число модификаций. Так вот, такого алгоритма еще нет. Есть ряд алгоритмов, позволяющих заметно ускорить сборку по сравнению с традиционными шаблонными методоми, но повторять кем-то уже проложенный (математически) путь мне показалось скучным. Если кому интересно, вот хороший анализ Далее есть традиционные шаблонные методы. Идея здесь в послойной сборке снизу вверх с использованием формул. Формула — последовательность модификаций Кубика, приводящая к таким-то целевым модификациям, и таким-то побочным. Соответственно, побочные модификации почти всегда падают на еще не собранные слои. Различаются шаблонные методы уровнем детализации шаблонов. Всякого рода спидкуберы знают все мыслимые шаблоны для большого количества частных случаев, что позволяет отыграть лишнюю 0.1 секунду с каждой модификации на соревнованиях. Пример, на что еще можно потратить жизнь.

Итак, я постепенно формировал для себя задачу. В итоге, формулируется она так: за кратчайшее реальное время необходимо написать решалку для Кубика Рубика.

Что мы знаем о Кубике? Число его состояний описывается как

(8! × 3^7) × (12! × 2^11)/2 = 43 252 003 274 489 856 000

.

Не так давно в рабочей рассылке обсуждалась тема использования буквы «ё» в документации и постах.
Обсуждение затянулось на несколько месяцев…

Осознав важность проблемы, написал ёфикатор на Node.js.

Предлагаем вашему вниманию подборку с ссылками на полезные ресурсы, интересные материалы и IT-новости

Я надеялся, что это было временно. Я надеялся, что 2015 год будет годом производительности. Я ошибался. Средний вес веб-страницы возрос на 7.5% за пять месяцев, превысив 2Mb. Для этого же потребуется три 3.5-дюймовые дискеты двойной плотности!

Согласно отчёту на HTTP Archive за 15 мая 2015, статистика, собранная на почти половине миллиона веб-страниц, такова:

Google, Microsoft, Mozilla и инженеры проекта WebKit 17 июня сделали анонс, что они объединились для запуска WebAssembly, нового бинарного формата для компилирования веб-приложений.

Генеральное собрание Ecma International объявило о ратификации стандарта ECMA-262 6 версии, который является спецификацией языка ECMAScript 6 (ES6), который так же называют ECMAScript 2015.

Несколько часов назад был опубликован финальный релиз спецификации ECMAScript 2015 ранее известной как ES6 — новый стандарт языка JavaScript.
Первым об этой новости сообщил основной идеолог языка и официальный представитель комитета по стандартизации Allen Wirfs-Brock.

Официальный документ доступен в форматах HTML и PDF.

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

Основные проблемы, которые встречаются в библиотеках валидации данных

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

Проблема №2. Процедурное описание правил валидации. Я не хочу каждый раз думать про алгоритм валидации, я просто хочу описать декларативно, как должны выглядеть правильные данные. По сути, я хочу задать схему данных (почему не «JSON Schema» — в конце поста).

Проблема №3. Описание правил валидации в виде кода. Казалось бы, это не так страшно, но это сразу сводит на нет все попытки сериализации правил валидации и использования одних и тех же правил валидации на бекенде и фронтенде.

Проблема №4. Валидация останавливается на первом же поле с ошибкой. Такой подход не дает возможности подсветить сразу все ошибочные/обязательные поля в форме.

Проблема №5. Нестандартизированные сообщения об ошибках. Например, «Field name is required». Такую ошибку я не могу показать пользователю по ряду причин:

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

То есть, нужно возвращать не сообщение об ошибках, а стандартизированные коды ошибок.

Проблема №6. Числовые коды ошибок. Это просто неудобно в использовании. Я хочу, чтобы коды ошибок были интуитивно понятны. Согласитесь, что код ошибки «REQUIRED» понятней, чем код «27». Логика аналогична работе с классами исключений.

Проблема №7. Нет возможности проверять иерархические структуры данных. Сегодня, во времена разных JSON API, без этого просто не обойтись. Кроме самой валидации иерархических данных, нужно предусмотреть и возврат кодов ошибок для каждого поля.

Проблема №8. Ограниченный набор правил. Стандартных правил всегда не хватает. Валидатор должен быть расширяемый и позволять добавлять в него правила любой сложности.

Проблема №9. Слишком широкая сфера ответственности. Валидатор не должен генерировать формы, не должен генерировать код, не должен делать ничего, кроме валидации.

Проблема №10. Невозможность провести дополнительную обработку данных. Практически всегда, где есть валидация, есть необходимость в какой-то дополнительной (часто предварительной) обработке данных: вырезать запрещенные символы, привести в нижний регистр, удалить лишние пробелы. Особенно актуально — это удаление пробелов в начале и в конце строки. В 99% случаев они там не нужны. Я знаю, что я до этого говорил, что валидатор не должен делать ничего кроме валидации.

3 года назад, было решено написать валидатор, который не будет иметь всех вышеописанных проблем. Так появился LIVR (Language Independent Validation Rules). Есть реализации на Perl, PHP, JavaScript, Python (мы на python не пишем — фидбек по ней дать не могу). Валидатор используется в продакшене уже несколько лет практически в каждом проекте компании. Валидатор работает, как на сервере, так и на клиенте.