JavaScript *

Многим хорош сервис поиска вакансий 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-хранилище).

В наше время для разработки фронтенда существует много фреймворков и библиотек. Есть хорошие, есть не очень. Часто нам нравится только какая-то концепция, модуль или синтакс. Универсальных инструментов не существует. В статье я описываю фреймворк будущего – такой, которого ещё нет. Я собрал достоинства и недостатки известных фреймворков и мечтаю об идеальном решении.

Абстракция опасна

Всем нравится простота. Сложность убивает. Она усложняет работу и приводит к крутой кривой обучения. Программистом нужно понимать, что как работает – иначе они чувствуют себя неуверенно. При работе со сложной системой есть большое расстояние между «я её использую» и «я знаю, как это работает». К примеру, следующий код прячет сложность:

var page = Framework.createPage({
	'type': 'home',
	'visible': true
});

Допустим, это реальный фреймворк. createPage где-то создаёт новый класс Вида, загружающий html-шаблон home. Основываясь на параметре visible мы добавляем созданный DOM-элемент к дереву. С точки зрения разработчика мы не знаем, как это всё работает в деталях, потому, что это – абстракция.

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

Если мы поменяем пример на следующий:

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



Год прошёл, второй учебный сезон скоро закончится и можно подвести итоги, поделиться планами и ответить на главный вопрос:

Хех, мне всегда хотелось написать один из этих «Х считается вредным» постов.

Прежде чем я начну, позвольте сказать следующее: я считаю что jQuery оказал просто невероятное влияние на продвижение Web. Он дал возможность разработчикам делать такие вещи, которые ранее считались немыслимыми. Заставил производителей браузеров реализовать многие фичи нативно (без jQuery у нас наверное никогда бы не появился document.querySelectorAll). jQuery всё еще нужен тем, кто не может положиться на современные плюшки и вынужден поддерживать реликты вроде IE8 или хуже.

Во всех современных системах сборки фронтенда есть режим watch, при котором запускается специальный демон для автоматической пересборки файлов сразу после их сохранения. Также он есть и gulp.js, но с некоторыми особенностями, делающими работу с ним немного сложней. Работа gulp.js основана на обработке файлов как потоков данных (streams). И ошибки в потоках не всегда можно перехватить, а когда ошибка случается, то будет выброшено неперехваченное исключение и процесс завершится.

Чтобы этого не происходило, и watcher мог игнорировать отдельные ошибки и запускаться снова и снова при сохранении файлов, в gulp нужно сделать несколько дополнительных настроек, о которых и расскажется в этой статье.