Здравствуй, Хабр!

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

• Раздача на Рутрекере (видео+слайды)
• Прямые ссылки на видеофайлы: первая лекция, вторая, третья, четвертая, пятая, шестая и седьмая
• Прямая ссылка на слайды (zip-архив pdf-файлов)
• Подкаст в iTunes
• Плейлист на YouTube
• Форум курса

Первая лекция: Введение в JavaScript, немного истории, числа (тут есть ошибка: функция toFixed округляет значения).



Остальное – под катом.

DOM Mutation Events в свое время казались отличной идеей — веб-разработчики начали создавать более динамичные приложения, и казалась естественной та радость с которой были встречены новые возможности прослушивать изменения DOM и реагировать на них. На практике, однако, оказалось, что у DOM Mutation Events имеются серьезные проблемы с производительностью и стабильностью. Не удивительно, что спецификация через год получила статус “устаревшей”.

Но сама идея, лежащая в основе DOM Mutation Events казалась привлекательной и поэтому в сентябре 2011 г. группа инженеров Google и Mozilla представила предложение о DOM MutationObserver, с похожей функциональностью, но улучшенной производительностью. Это новое DOM-API доступно начиная с версий: Firefox 14, Chrome 18, IE 11, Safari 6 (остальные браузеры — caniuse.com/mutationobserver)

AngularJS директивы – это клево

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

Приветствую всех, уважаемые харбажители!
В данном посте речь идет о том, как подружить карты яндекса и javascript framework angular.js для их совместной работы. Можно, конечно, использовать и google map, но для стран СНГ их качество оставляет желать лучшего.
Немного погуглив, и не найдя готового решения, пришлось писать свое. Кому интересно, добро пожаловать под кат.

Начало

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

Не секрет, что в последнее время IT компании тратят очень много сил и ресурсов на «удержание сотрудников». У меня лично складывается впечатление, что «удержание сотрудников» — это что-то про манипуляции и не слишком честных руководителей. А для того, чтобы ребята оставались работать в вашей команде, достаточно вовремя платить конкурентную зарплату, дать им интересные проекты и создать условия, в которых им будет комфортно работать.

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

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

Надеюсь, данные результаты будут интересны и полезны многим :)

Часто мы делаем проекты продолжительностью в несколько месяцев. При этом горизонт планирования команд в Сибириксе — порядка пяти недель. В переложении на спринты — 3-5 спринтов (зависит от опыта конкретной команды).

Я использую два монитора, Google-календарь, Scrumban, общую тетрадь и песочные часы. Сам способ постоянно дорабатывается, но общие принципы остаются неизменными: держать под рукой все проекты в рукописном виде + управлять движением проектов на виртуальной канбан-доске.



Сама процедура занимает 2 часа в неделю. Этого времени достаточно, чтобы распланировать нагрузку примерно на 35-50 человек. Удобно делать либо рано утром в понедельник, либо в пятницу, во второй половине дня, либо в воскресенье вечером.

JavaScript, the winning style

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

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

В отличие от Питона у которого есть единый свод правил «Style Guide for Python Code», у языка JavaScript такого нет. Однако на выбор есть целых 6 популярных гайдов:

• Google JavaScript Style Guide
• npm’s coding style
• Felix’s Node.js Style Guide
• Idiomatic JavaScript
• jQuery JavaScript Style Guide
• Douglas Crockford’s JavaScript coding style

Помимо гайдов, не стоит так же забывать об автоматических анализаторах кода, таких, например, как JSLint и JSHint. И в них уже заложены свои настройки. Вопрос в том, какой же все-таки максимально правильный способ писать код на JavaScript, который был бы актуален и максимально соответствовал бы большинству рекомендаций? Давайте попробуем объединить большинство рекомендаций в этой статье и подумаем как можно оптимизировать процесс проверки качества кода.

Годами я использовал Chrome DevTools, Firebug и даже Opera Dragonfly для отладки, трасировки и профилирования моего JavaScript кода. Замечу, что использовал эти замечательные инструменты не только для работы с JavaScript, но и для отслеживания событий сети, отладки CSS, работы с DOM.

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

Всем привет!
Ровно год назад, 12 июля, был опубликован пост о задумке собирать бесплатные шрифты и организовать удобный доступ к ним. Именно эту дату будем считать днем рождения нынешнего WebFont.ru.
Сегодня будет повествование о том, что и как удалось сделать.

В итоге ролик мы сняли сами, без опыта и с минимальным бюджетом. Получилось лучше, чем думали: в первые сутки 1500+ просмотров и рекордно много лайков на нашей fb странице. Позитива в комментариях добавило то, что делали всё сами. Для молодого банковского сервиса с особым походом к обслуживанию этот позитив получился как нельзя кстати.



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

Для управления зависимостями в проекте, node.js, как и многие другие платформы, предоставляет собственный пакетный менеджер — npm. И несмотря на то, что он внешне похож, например, на Ruby Gems, и вроде бы выполняет те же самые функции, npm обладает некоторыми особенностями, которые стоит учитывать при разработке приложений на node.js. Одна из таких особенностей — это способ хранения директории node_modules в проекте. Многие, по аналогии с другими системами, оставляют в проекте только package.json с зафиксированными версиями модулей, а node_modules добавляют в .gitignore. Такая стратегия не всегда верна, если мы обратимся в FAQ на npmjs.org, то увидим там следующее:

Q: Стоит ли хранить node_modules в git?
A: Mikeal Rogers очень хорошо ответил на этот вопрос:
http://www.mikealrogers.com/posts/nodemodules-in-git.html
tl;dr

• Храните node_modules в git для проектов, которые требуется разворачивать, таких как вебсайты и приложения.
• Добавляйте node_modules в .gitignore для библиотек и повторно используемых модулей.
• Используйте npm для управления зависимостями в dev окружении, но не в скриптах используемых для деплоя.

Под катом перевод статьи Mikeal Rogers, в котором подробно описывается, с чем связан такой непривычный подход.

Хай, Хабр!
Сегодня я хочу представить, дорогому хабрасообществу свой первый хабраперевод. Программировать на языке Python — подобно песне. Но еще лучше, когда Ваш код читаем и понятен, а значит чуть более поэтичен, чем обычно бывает производстве. У каждого свои правила и свои стереотипы относительно написания и оформления исходного кода, на каком бы языке он ни был написан. Множество копий сломано о щиты на форумах, но, как ни крути, нельзя не считаться с мнением авторитетных товарищей. Так что сейчас будет представлен перевод первой части стайл-гайда для языка Python от Google. Коснется он именно постулатов написания кода (вторая часть тоже скоро появится, а посвящена она будет форматированию исходного кода). Сразу предупреждаю: тут много (если не большая часть) прописных истин, которые все знают уже давно. Но я искренне надеюсь, что Вы сможете найти тут что-то новое или хотя бы вспомнить старое. Приступим под катом. И pdf тут как тут.

Как часто Вы используете конструкции вида «5 минут назад», «Полчаса назад» на вашем сайте? А что если пользователь открыл вкладку и забыл про нее на пару часов? «5 минут назад» явно теряет свою актуальность.
Именно для того чтобы исправить это досадное недоразумение служит uptodate.js

С traceGL можно увидеть весь JavaScript поток в шустром webGL визуализаторе. Это как осциллограф, только для кода.

На сайте traceGL предлагают купить за $14.99 или € 11.50

Для начала, ликбез и несколько фактов:

• ECMAScript — это официальный стандарт языка JavaScript (Слово JavaScript не могло быть использовано, потому что слово Java являлось торговой маркой компании Sun) Т.е. JavaScript — это имплементация стандарта ECMAScript.
• TC39 — комитет, развивающий стандарт ECMAScript и принимающий решения по включению фич в него.
• ECMAScript стандартов много. Самый популярный из них — ECMA-262.
• ECMAScript 5 — последняя редакция стандарта ECMA-262 (утвержден в 2009 году).
• Предыдущие версии стандарта ECMA-262 были (совсем старые не упоминаю):
  
  • ECMAScript 3 — поддерживается большинством браузеров (утвержден в 1999 году).
  • ECMAScript 4 — не принят в виду слишком радикальных изменений в стандарте. Позднее в июле 2008 году в урезанном варианте (но все же намного богаче, чем ECMAScript 3) вылился в новый проект ECMAScript Harmony.
  
  
• ECMAScript 6 (кодовое имя ECMAScript.next) должен утвердиться до конца 2013 года.

Итак, что же нас ждет в новой версии JavaScript?

Здравствуйте!

Я — Фёдор furikuretsu Ананьев, веб-разработчик студии Hot Dot, и сегодня я дам несколько простых советов для тех, кто хочет сделать своё JS-параллакс-приложение очень и очень быстрым.

^{Затемнение фоновых дисплеев и подсветка изменений по методу PixMap}

Если вы работаете с несколькими мониторами, то наверняка понимаете проблему. Переведя взгляд с одного экрана на другой, трудно быстро понять, что там изменилось. Технология Diff Displays должна помочь в таких ситуациях. Если вкратце, то система отслеживает направление взгляда пользователя. Если взгляд уходит с дисплея, то там активируется промежуточный слой, который затемняет или обесцвечивает картинку, выделяя при этом изменения. Как только взгляд возвращается, дисплей тоже возвращается в нормальное состояние. Вместо затемнения и обесцвечивания могут использовать и другие методы, см. видео под катом.

Эта маленькая библиотека позволяет очень просто создать пошаговое введение для сайта или приложения. Достаточно добавить атрибуты data-intro и data-step с описанием и номером шага соответственно к нужным элементам страницы. Вот так:

<a href='http://google.com/' data-intro='Hello step one!' data-step='1'></a>

Как частый посетитель тэга PHP на StackOverflow, я очень часто встречаю вопросы о том, как распарсить какие-то конкретные аспекты HTML, используя регулярные выражения. Самый распространённый ответ на это:

«Ты не можешь парсить HTML с помощью регулярных выражений, потому что HTML не является регулярным. Используй XML парсер, и будет тебе счастье»

Это утверждение — в контексте вопроса — находится где-то между сильно вводящим в заблуждение и абсолютно неправильным. Что я хочу попытаться продемонстрировать в этой статье, так это то, насколько могущественны современные регулярные выражения на самом деле.