JavaScript *

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

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

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

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



График позволяет:

• Увидеть работу JavaScript-таймера в реальном времени.
• Смоделировать разные условия нагрузки.
• Сравнить работу разных браузеров.
• Даёт информацию к размышлению (некоторые результаты оказались любопытными).

Всем доброго времени суток

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

Но возникла необходимость внедрить в проект поддержку сервиса CardIO. CardIO предоставляет функционал для сканирования фронтальной части кредитной карты. Информация о cvv вводится вручную.

Поискав на сайте Cordova плагин для этого сервиса, и выбрав среди нескольких существующих вариантов, остановился на этом — Plugin. Использовать его в чистом виде не хотелось, потому решил написать Angular обертку для этого плагина, для его дальнейшего использования.
В итоге получилось следующее angular-cordova-cardio

JavaScript – один из главных языков нашего стека в Хекслете. Мы используем ReactJS и NodeJS в интерактивных частях платформы, и сделали вводный курс (более продвинутые – на подходе). Любовь к JS помогла опубликовать этот перевод хорошего эссе «Prototypes are Objects (and why that matters)».

Этот пост рассчитан на тех, кто знаком с объектами в JavaScript и знает, как прототип определяет поведение объекта, что такое функция-конструктор и как свойство .property конструктора относится к объекту, который он конструирует. Общее понимание синтаксиса ECMAScript 2015 тоже не помешает.

Мы всегда могли создать класс в JavaScript таким образом:

Насколько быстро можно создать устройство для Интернета вещей (IoT), которое управляется через браузер, получает и передает информацию, учитывая, что вы никогда не работали с микроконтроллерами, а только занимались высокоуровневым программированием на JavaScript?



Например, такое устройство как на фото. У него есть ЖК-экран и стрелочный указатель на сервоприводе. Рядом лежит телефон с запущенным браузером, который подключен к вебсерверу на устройстве. При нажатии стрелок в браузере, указатель поворачивается вправо, влево или устанавливается в нейтральное положение. После установки значения, оно передается обратно в браузер и показывается как значение Value. Дополнительно в браузере можно задать текстовую строку, которая после нажатия кнопки «Set text» выводится на ЖК-экране. Всё взаимодействие происходит по Wi-Fi. Как вы думаете, сколько времени уйдёт на разработку?

Тема 30-й встречи петербургского технического сообщества IT talk «Компоненты, React и Flux» оказалась настолько актуальной, что мест в зале не хватило. Выступал Даня Абрамов, который сейчас занимается опенсорсом и консалтингом по проектам, написанным на React.js.

React — относительно новый фронтенд-фреймворк, продукт компании Facebook. Но Даня говорил, скорее, не про React, а про его парадигму, которая существенно меняет подход к UI-приложениям. Он отметил, что сейчас самые интересные инновации в UI-приложениях происходят именно в вебе.



P.S. Извините за качество записи и проблемы со звуком. Решили, однако, что контент стоит того, чтобы поделиться.

Вступление

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

К сожалению с javascript такой номер не прокатывает — Livereload не знает как гуманно заменить только изменившиеся скрипты и перегружает всю страницу. Это особенно печалит если использовать инструмент вроде mithril, в котором представление (читай — html) задается так же в javascript. Если я меняю модель или контроллер, то тут все понятно, но если я меняю класс у дива в представлении (скажем, подбирая правильное сочетание bootstrap классов), то перезагрузка страницы кажется излишней — ну вот же, я поменял одну функцию, просто перерисуй view с ее помощью!

В целом не страшно, конечно (работали же как-то без этого раньше), но почему бы не сделать работу еще немного удобнее?

Для тех, кто торопится

• репозиторий с демонстрацией — склонировать, npm install, gulp serve
• Анимация того, что получилось в итоге

  
  

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

Каждый программист неоднократно сталкивался с необходимостью проверки пользовательского ввода. Занимаясь веб-разработкой уже более 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 не пишем — фидбек по ней дать не могу). Валидатор используется в продакшене уже несколько лет практически в каждом проекте компании. Валидатор работает, как на сервере, так и на клиенте.

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

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

Ответы на эти вопросы можно при желании легко найти в сети, но придётся перечитать дюжину статей, и на каждый вопрос ответов будет, скорее всего, несколько. Некоторое время назад мне понадобилось написать небольшой туториал по node.js, который бы позволил быстро запустить разработку и познакомить новых программистов в проекте с этой технологией. Рассчитан он на опытных Java-разработчиков, которые и язык JavaScript хорошо знают, но node.js как платформа для бэкэнда для них в новинку.

Думаю, что данная статья будет полезна не только разработчикам из мира Java, но и всем, кто начинает работу с платформой node.js.

Добра всем хаброчитателям!

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

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

Многим хорош сервис поиска вакансий hh.ru, но ищущий всегда найдёт, что усовершенствовать. К примеру, на сервисе есть поле для заполнения письма — ответа на вакансию, но нет элементарного шаблона оформления письма — заголовок, кратко о себе, ответы на требования по вакансии.

Если нет — надо сделать. Ведь специалист по JS не будет многократно заниматься Copy-Paste-операциями, когда знает, что их можно автоматизировать, даже не обременяя просьбами службы сайта. Есть такие инструменты, как пользовательские скрипты.

UPD 12.1.2016: Скрипт расширен на сайты career.ru (клон HH с той же клиентской базой), itmozg.ru, superjob.ru.

Вначале, конечно, пришлось покопировать, пока не выявились закономерности и не получился юзерскрипт hhFiller. Шаблон отклика, на мой взгляд, должен содержать:
1. Заголовок-приветствие. После него пойдёт сразу рукописный текст, живой ответ на вакансию в 2-3 или более строчек.

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

Прочитали? Дальше будет про лучший в мире язык программирования, который я назову ближе к концу. Да, да, еще три дня назад я и не думал что единороги существуют — ведь каждый язык так или иначе сосет, и каждый сосет по-своему (хотя нет, есть и такие которые сосут всегда и везде, но о них не будем). Как инженер, я прекрасно понимал что в вопросе языка не возможно без разнообразных trade offs, начиная с garbage collected vs manual memory management, хотя Rust пытается съесть рыбку не присев на палку в этом вопросе, и так далее. Хоть мы и говорим о языках общего назначения, все они так или иначе позиционируют себя, фокусируясь на каких-то идеях, принципах, и целях, в которых они хороши, оставляя все не согласованное с такими принципами в лучшем случае возможными, но не эффективными и/или не удобными. Одним словом нецелесообразными. Однако язык, сочетающий в себе несочетаемое, есть.

«KISS (keep it short and simple — «делай короче и проще») — процесс и принцип проектирования, при котором простота системы декларируется в качестве основной цели и/или ценности.» Wikipedia

Введение

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

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

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

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

Оригинал: React To The Future With Isomorphic Apps

Изоморфные приложения. Взгляд в будущее с React

В разработке программного обеспечения все часто возвращается на круги своя. Так, например, на заре развития Интернета серверы подгружали контент сразу же на сторону клиента. В последнее же время, с разработкой современных веб-фреймворков, таких как AngularJS и Ember, мы видим тенденцию к обработке запросов на стороне клиента и использованию сервера только для API. Однако, это далеко не единственная тенденция. Сейчас происходит медленное возвращение или, скорее, слияние этих двух архитектур.

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

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