/[^@]+@[^@\.]+\.[^@]+/

Оговорка “на клиенте” сделана не просто так. Задача валидации на клиенте – подсказать пользователю, где он ошибся в написании email-а. Важно случайным образом не запретить пользователю с непредусмотренным емейлом воспользоваться формой. Учитывая то, какие варианты емейла могут быть (неожиданные домены, появляющиеся по пучку каждый месяц, ip адреса в качестве домена, и символы точки и симполы +, и другие неизвестные широкому обывателю вещи), напрашивается вывод, что лучшая валидация проверит емейл на наличие текста вида текст-собачка-текст-точка-текст.

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

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

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

Метеор – фреймверк, который включает в себя полный стек разработки: клиент, сервер, бд. Метеор реализовал собой концепцию “один и тот же код для клиента и сервера”.

Я начал знакомство с этим фреймверком с версии 0.4, уже два года как. Параллельно я смотрел на другие инструменты, разрешающие те же задачи, что и метеор (expressjs, socketio, sailsjs, backbone, mongoosejs, swarmjs, react, и другие, названия которых так и не вспомню). Я искал и подбирал те инструменты, которые позволят быть мне продуктивным, создавать и поддерживать проекты самостоятельно. Инструмента лучше метеора, я не нашел.

Что делает метеор: он радикально упрощает разработку приложений.

1. Используется один и тот же код для сервера и клиента. Я рад, что был выбран чистый js, а не какой-нить кофе (хотя код на кофе можно использовать наравне с js, нужно только добавить соответствующий пакет).
2. Подход к работе с базой данных на клиенте и сервере одинаковый. Один и тот же код работы с данными используется как для клиента, так и для сервера. Это достигается эмуляцией mongo api в браузере (с некоторыми ограничениями). Ограничение данных, доступных для клиента описывается в одном месте.
3. Большинство вещей, нужных для разработки идут из коробки: бутсрапинг приложения, темплейты, данные, пакетная система, сборка-минификация проекта, работа с аккаунтами и почтой. Бесплатный хостинг и деплой на него в одну команду. Пока не хватает нативного деплоймент менеджера из коробки (сейчас пользуюсь сторонним https://github.com/arunoda/meteor-up, деплою на digitalocean, ненарадуюсь), не хватает фреймверка для тестирования из коробки. Над этими пакетами сейчас идет работа.
4. Концепция реактивности. Код пишется так, что за обновлением данных на сервере следует немедленная реакция всех клиентов. На клиенте изменения данных отражаются автоматически на отображении страницы. Весь код, необходимый реактивности уже вшит в фреймверк (в работу с бд, темплейтами, сессионными данными). Работа с фреймверком сводится чисто к манипуляции с данными, без необходимости писать обертки-сихронизаторы, пробрасывать события, чтобы связать изменения зависимых данных.

Почему метеор имеет значение. История показывает, что выживают те технологии, которые решают задачи лучше других. Такие технологии как PHP, javascript выжили и распространились в большей степени не от того, что они хороши сами по себе, а потому что лучше других решали задачи (генерация html, и оживление страничек в браузере). Так вот метеор – это та технология, которая лучше других справляется с теми задачами, которые сегодня стоят перед веб разработчиками (работа с бд, изоляция вьюх, “умные” теплейты, деплой). javascript как язык, на котором говорит веб, одинаковые концепции для сервера и клиента, отсутствие необходимости совершать выбор стека технологий, необходимые инструменты из коробки: все это делает разработку на метеоре намного проще, если сравнивать с разработкой на самособранном стеке (сервер expressjs или connect, база mongodb, орм для базы mongoose, сокет-сервер socketio, клиент angular, backbone + react, что-то для деплоя и т. д.).

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

Из минусов.

1. Метеор – это полный стек. И так или иначе придется мириться с тем выбором, который был сделан создателями (в плане движка теплейтов, реактивности, подхода к работе с событиями и т. д.). Я понимаю, что хочется использовать знакомые вещи вместо незнакомых потому что так проще. Поэтому я считаю что метеор не подходит для тех, кто не готов довериться этому стеку технологий.
2. Целый набор новых парадигм (во всяком случае подходы метеора отличаются от тех, с которыми я сталкивался, разрабатывая сайты на expressjs и socketio). Новые парадигмы порождают непривычные проблемы. Попытка применить опыт разработки на том же expressjs к работе с метеором ведет к большему количеству вопросов, чем ответов.
3. Не поддерживается windows. Разработку из под винды вести сегодня не получится. Поддержка винды – это то, над чем сейчас активно ведется работа.

Для знакомства с технологией:

Пошаговый туториал
https://www.meteor.com/install

Документация на английском
http://docs.meteor.com/#/full/

Книженция, где создают приложение на метеоре
https://www.discovermeteor.com
и ее перевод http://ru.discovermeteor.com/

Годный блог про то как работают кишечки фреймверка
http://meteorhacks.com

Поиграться с метеором без необходимости его устанавливать (или чтобы поразрабатывать из-под винды):
http://meteorpad.com

Раздел форума, где я могу помочь и подсказать по метеору
http://forum.jscourse.com/c/meteor

1. Имя переменной должно называться сущностью из предметной области. Чем абстрактнее название переменной, тем сложнее понимать программу.

// Абстрактно
function drive(settings) {}

// Конкретно
function drive(pathDirections) {}

2. Если думать о программе на русском, то не всегда нужное слово для названия переменной с легкостью извлекается из головы. В таком случае можно воспользоваться электронным переводчиком. Он же предложит несколько вариантов перевода одного и того же термина.

3. Синонимы могут быть лучше первого вспомнившегося перевода. Пользуйся http://thesaurus.com для поиска синонимов. Там же найдешь антонимы.

Какими еще способами можно улучшить именование переменных?

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

С помощью аннотаций удобно указывать что происходит, а не как это происходит. Например, реальность такова, что для подобного результата, к примеру, наследование класса, существует множество библиотек и подходов. Каждый фреймверк несет свой подход. Чтобы понять, какие методы содержаться в экземпляре класса (для удобного автокомплита), прийдется выполнить весь js код. Аннотации же позволяют указать зависимость между классами, не указывая как именно эта зависимость реализована.

/**
 * @constructor
 */
function EventEmitter() {}
EventEmitter.prototype.on = function () {}
EventEmitter.prototype.off = function () {}
EventEmitter.prototype.trigger = function () {}


/**
 * @constructor
 * @extends EventEmitter
 */
function Model() {}
Model.prototype.ready = function () {}

/**
 * @constructor
 * @extends Model
 */
function UserAccount() {}

var ua = new UserAccount(1)

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

А так же переходить к определению класса, от которого происходит наследование

Теперь о недооцененных аннотациях
@event описывает событие подобно еще одному типу данных. Метод, который стреляет событие описывается с помощью аннотации @fires. А так же метод, который слушает событие помечается аннотацией @listens. При корректной поддержке редакторами (я скорее ожидаю этого от webstorm), установить порядок связей в приложении становится намного проще. Реалии веб разработки такие, что почти все проекты используют EventEmitter, Mediator, Stream паттерны. Используя аннотации и продвинутый редактор, установить связь между классами, методами не составляет большой сложности. Большая сложность заключается в понимании того, как связаны объекты между собой, когда объекты подписываются на события. Место, где стреляется событие приходится искать вручную.

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

Из хороших новостей – поддержка этих аннотаций запланирована.

Качество правописания у меня страдает. Решение – автоматическая проверка набираемых текстов прямо на уровне движка. Правописание можно проверять в комментариях и при наборе статьи. Для проверки используется API Яндекс спеллера.

Код и инструкция по установке – на гитхабе: https://github.com/podgorniy/blogengine-speller

Классы – круто. В es < 6 Так или иначе приходилось эмулировать создание классов, хоть и на прототипном наследовании. Поддержка на уровне языка дает чистый читабельный код.

Деструктивное присваивание, оператор spread и rest arguments используется не так часто, как мне казалось, когда я думал о es6.

Функции-стрелки – круто. Хоть я и писал серверный код, все равно пару раз понадобились, сделали код чище. Требуют сноровки и внимательности, чтобы не превратить код в нечитаемую лапшу, когда вкладываются одна в другую. Возможно я всего лишь еще не научился читать es6.

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

Как только проект чуть разросся (5 классов), столкнулся с бедной поддержкой языка редактором (писал в саблайме). Переход к методу или классу не работает, а пользоваться поиском не с руки. Еще столкнулся с проблемой с подсветкой синтаксиса. Из-за непривычности синтаксиса допускал много ошибок, которые в редакторе не были видны, и приходилось запускать приложение, а потом из stack trace понимать в какой строке допустил описку.

Эти два фактора свели на “нет” все прелести нового стандарта, и в итоге недоделанный проект я переписываю на es5.на

Общие впечатления от es6 – самые теплые. Через пол года повторю эксперимент.

Писал код, прогоняя его через traceur-compiler. Для ноды разработка происходит прозрачно: скрипт инициализации проекта подтягивает traceur, тот умеет переписывать функцию импорта модулей, я указываю какие модули являются es6, и при их импорте traceur, прогоняет содержимое через свою магию. Все преобразования es6-es5 происходят в памяти, дополнительных файлов не создается. Проект стартует-рестартует быстро.

Если не понятно о чем я говорю, и интересно, то тут можно найти список статей, рассказывающих про новшества es6. А тут – посмотреть на слайды с моего выступления на оную же тему. (чтобы увидеть заметки к слайдам, перейди в режим перезентующего, нажав на клаве S)

UPD Поддержка Webstorm-ом es6 на порядок лучше того сетапа, которым я пользовался https://www.youtube.com/watch?v=jbfkcmxLLKY