JavaScript *

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

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

JavaScript библиотека jQuery была выпущена 9 лет назад и с тех пор этот open source проект внес ощутимый вклад в мир веб-разработки. Безусловно интересно оглянуться назад и посмотреть на истоки jQuery.

В апреле 2015 года создатель jQuery Джон Резиг (John Resig) опубликовал самую первую версию jQuery от января 2006 года. В этой публикации Джон дополнил код воспоминаниями о том, как создавался jQuery.

Вот несколько фактов, которые можно узнать изучая комментарии Джона:

Всем привет! В нашем предыдущем посте про облачный сервис Cackle мы рассказали об архитектуре, технологиях и нагрузках в целом. Сегодня хотим поделиться о том, как в условиях столь сильных нагрузок и уже накопленной информации (30 000 000 комментариев с 2011 года) мы сделали подробную аналитику для системы комментариев Cackle. Наш метод сбора статистики универсальный и думаю будет интересен, в плане практического применения, всем тем, кто столкнулся с задачей разработки аналитики, но пока не совсем представляет с чего начать.

Предисловие

— Что делает русский человек в кризис?
— Как можно быстрее тратит все свои деньги.

Железка

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

Захожу в интернет магазин и, что вы думаете, не нахожу там своего любимого старого доброго лампового… (подставить свое) тетриса. Надо исправить.

Лето набирает силу, и разработчики Webix позаботились о том, чтобы вам было чем себя занять в отпуске или на каникулах. Не так давно в их блоге появился пост о новой, за номером 2.4, версии фреймворка. Новые фичи, обновления, длинный список багфиксов. Очень увлекательно! Давайте посмотрим подробнее, что для нас приготовили.

К слову говоря, если вы слышите это название впервые и вообще не понимаете, о чем речь, здесь доступен мой небольшой Webix-туториал.

Предлагаю читателям «Хабрахабра» перевод статьи «How I learned to stop worrying and love React».

Если вы спросите меня, что я думал о React два месяца назад, я бы сказал…

Где мои шаблоны? Что этот сумасшедший HTML делает в моем JavaScript? JSX выглядит странно! Скорее! Сжечь это!

Это потому, что я его не понял.

Но я уверяю, React — это определенно правильный путь. Пожалуйста, выслушайте меня.

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

        Возможности меню, реализованные в данной статье:

1. Вся начинка меню спрятана под капотом директивы. При верстке html страницы указывается лишь DOM-элемент с директивой, что повышает читабельность кода.
2. У меню есть возможность создавать пункты с бесконечным уровнем вложенностей.
3. Подсветка активной страницы в меню осуществляется не только на первом уровне, но и на любом уровне вложенности.
4. Возможность зарегистрировать пункт меню на этапе конфигурации приложения.
5. Возможность отображения/сокрытия конкретных пунктов меню в зависимости от прав доступа текущего пользователя.

        Исходный код директивы можно посмотреть тут.

1 Введение

В статье мы сравним три популярных MV* фреймворка для веб-разработки: AngularJS, Backbone и Ember. Выбор подходящего фреймворка для проекта кардинально влияет на вашу возможность выполнять задачи вовремя и поддерживать ваш код в будущем. Вам нужен надёжный, проверенный фреймворк, но вы не хотите, чтобы он вас ограничивал. Веб быстро развивается, и старые методики уходят в прошлое. Займёмся же подробным их сравнением.

2 Познакомьтесь с фреймворками

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

AngularJS родился в 2009 как часть большего коммерческого продукта GetAngular. Вскоре после этого Миско Хевери, один из инженеров-основателей GetAngular, сумел воссоздать при помощи этого продукта веб-приложение, состоявшее из 17 тысяч строк кода и делавшееся в течение 6 месяцев, всего за 3 недели, и уложиться при этом в тысячу строк кода. В Google впечатлились таким фактом и стали спонсировать проект с открытым кодом AngularJS. Среди его возможностей – двустороннее связывание данных, инъекции зависимостей, простой для тестирования код и расширение возможностей HTML при помощи директив.

Backbone.js – легковесный MVC-фреймворк, родившийся в 2010. Популярность набрал в качестве альтернативы тяжёлым фреймворкам вроде ExtJS.

Ember родом из 2007 года. Он начинался как SproutCore MVC фреймворк, и сначала его разрабатывали SproutIt, затем – Apple. В 2011 году его форкнул Иехуда Кац, один из главных программистов в проектах jQuery и Ruby on Rails.

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

Предположим, мы разрабатываем простой пакет для npm. Назовём его, например, storage (хранилище). Заранее предусмотрим возможность использования одного из нескольких типов хранилищ, например, FsStorage (файловое хранилище), MysqlStorage (MySQL-хранилище), MongoStorage (Mongo-хранилище).