JavaScript *

Всем привет, и ещё раз всех с прошедшими праздниками. Трудовые будни набирают обороты и вместе с ними растёт информационный голод мучающий нас. Мир разработки переднего конца не дремлет и готовит нам много сюрпризов в наступившем году, и уж поверьте мне, скучно не будет ни кому. Одна из новых особенностей которые нам готовят разработчики браузеров совместно с группами разработчиков пишущих спецификации — JavaScript Promises(далее в переводе — Обещания, прошу сильно не бить) — полюбившийся многим шаблон написания асинхронного кода обзаводится нативной поддержкой. Что же такое обещания и с чем их едят можно прочесть в нижеследующем переводе(слегка вольном) замечательной статьи Джейка Арчибальда.

Это пост про небольшую игру «Крестики-нолики», которая была написана в целях пополнения опыта программирования на JS. Здесь применяются canvas и DojoBase. Библиотека используется для работы с событиями и для нахождения элементов по id(это очень удобно). Сanvas используется для отрисовки игрового поля.
Сама игра

Привет, Хабр! В институте у нас был курс 'Начертательная геометрия' из которого мы узнали, какие интересные вещи можно делать обычным циркулем и линейкой. С тех пор не покидала идея сделать что-нибудь на компьютере в духе объемных чертежных построений.

Не так давно с удивлением обнаружил, что мой ноутбук (далеко не самый новый и мощный) поддерживает стандарт WebGL. В результате некоторых усилий получился прототип системы создания и публикации 3D-иллюстраций.

http://ewclid.headfire.ru/

Интересная возможность, которую удалось реализовать — просмотр иллюстраций на 3D-телевизорах в стереорежиме без каких-либо драйверов и плагинов. Вывод осуществляется прямо из браузера в формате Side-By-Side.

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

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

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

Сайт перевода
Репозиторий на GitHub

Команда проекта GeeksLab 30 ноября 2013 года в Одессе провела VI специализированную конференцию FOSS Sea: back-end на базе свободных и открытых технологий. Один из потоков мероприятия был посвящен разработке бекенда на JavaScript. В данном потоке с докладами выступили представители таких компаний как: DataArt, Lohika, GlobalLogic, GradSoft, IT Adapter Corp и другие. Презентации и видеозаписи докладов под катом.

Зачем это надо? А вспомним ситуацию: в офисе работают несколько человек, и у одного к компьютеру подключены музыкальные колонки. — «Вась, смени LoveRadio! Поставь Рамштайна!» И Вася, отвлекаясь от отчета/игры/мысли: «Надоел Рамштайн, давайте лучше „Поющие трусы“ поставлю? Мегазачотные песни!»

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

Как веб-разработчик, вы, наверное, часто писали код JavaScript в одном файле, и, когда количество кода становится все больше и больше, его трудно поддерживать. Для решения этой проблемы вы можете разделить свой ​​код на несколько файлов, добавить дополнительные теги script и использовать глобальные переменные для доступа к функциям, объявленным в других файлах. Но это загрязняет глобальное пространство имен и для каждого файла дополнительный запрос HTTP снижает пропускную способность, что увеличивает время загрузки страницы.

Если это знакомо вам, наверное вы осознали необходимость в реорганизации вашего фронтенд кода, особенно если вы создаете крупно-масштабируемое web-приложение с тысячами строк кода JavaScript. Мы должны по-новому организовать всю эту неразбериху, чтобы код стало легче поддерживать. Новый метод заключается в использовании загрузчиков скриптов. В интернете можно найти много реализаций, но мы возьмем один из лучших, под названием RequireJS.

В этой пошаговой инструкции вы узнаете, как построить простое MVC (Model — View — Controller) приложение с помощью RequireJS. Вам не потребуются какие-либо предварительные знания в загрузке скриптов, основы мы рассмотрим в этой статье.

В настоящее время jQuery является де-факто библиотекой для работы с DOM. Она может использоваться вместе с популярными MV* фрэймворками (такими как Backbone), имеет множество плагинов и очень большое сообщество. С другой стороны JavaScript становится все популярнее и многие разработчики начинают интересоваться как работают стандартные API и когда можно просто их использовать, не добавляя дополнительную библиотеку.

В поздние дни работы с jQuery я начал замечать разные проблемы с этой библиотекой. Большинство из них основопологающие, поэтому не могут быть исправлены без потери обратной совместимости, что, конечно, важно. Я, как и многие другие, продолжал использовать библиотеку какое-то время, встречаясь с надоедливыми причудами каждый день.

Статья будет полезна web-разработчикам, которые задумались об отображении математических формул в браузере, ну и, наверное, другим IT-ам для общего развития.

У нас в компании уже давно внедрена система стимулирования сотрудников (KPI) на базе «Redmine», совмещающая функции расчета ЗП. Расскажу о ней в двух словах.

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

Все это может выглядеть примерно вот так:

В angular есть 2 инструмента вывода информации в DOM — это директивы и декларативный биндинг данных в HTML {{model}}.
В то время когда директивы обладают большими возможностями, декларативный биндинг немного ограничен, он делает $watch на модель с возможностью вызвать фильтры и по большому счету — все. А хотелось бы больше гибкости.

Например если посмотреть на библиотеку bindonce для Angular.js, основная идея — это разовый вывод информации без использования $watch.
И для того что-б её можно было использовать в любом месте, для любого атрибута, разработчик сделал ряд отдельных директив: bo-text, bo-href-i, bo-href, bo-src-i, bo-src, bo-class, bo-alt, bo-title, bo-id, bo-style, bo-value, bo-attr и bo-attr-foo. Но по сути, все они делают одно и тоже и по логике это должна быть одна директива.
Так же это отклоняется от декларативного биндинга данных, задуманного в Angular.js, т.е. вместо

<a href="{{link}}">{{name}}</a>

нужно писать

<a bo-href-i="{{link}}" bo-text="name"></a>

Т.е. для чего был придуман декларативный биндинг данных, в этой ситуации не работает.

Поэтому появилась идея реализовать директивы для декларативного биндинга данных.
Как это работает в Angular Light — просто нужно указать имя директивы и перед этим поставить знак "#", т.е. вместо {{model}} будет {{#directive model}}.
Бесполезный, но простой пример счетчика:

<div al-app>
    counter {{#counter model}}
</div>

Делаем биндинг «model» и подключаем директиву «counter», для простоты я опустил использование «model» в данной директиве:

alight.text.counter = function(callback, expression, scope, env) {
    var n = 0;
    setInterval(function(){
        n++;
        callback(n)  // set result
        scope.$scan()  // $digest
    }, 1000);
}

Если вы интересуетесь клиентским программированием, то как и я, вероятно, могли слышать о Meteor, уже не новом веб-фреймворке, который относится к набирающим популярность, так называемым «фулл-стек» фреймворкам. О нем уже писали на Хабре, чтобы не дублировать информацию, можно почитать здесь или тут. Я довольно давно слышал о метеоре, но все никак не решался его пощупать. И вот, пришли очередные выходные, и я снова наткнулся на него. В этот раз я решил честно попробовать, что это такое. Может быть, этот пост даст кому-то небольшой толчок к началу изучения или хотя бы знакомства с этим инструментом. Тогда это было бы не зря.
Disclaimer: может вызвать зависимость.
Давайте же сделаем первые шаги к освоению meteorjs, добро пожаловать под кат.

Представляем Om

Нам, в нашем ClojureScript-углу, это было известно уже давно — все наши структуры данных неизменяемы и основаны на оригинальных коллекциях из Clojure, написанных на Java. Современные JavaScript движки в настоящее время достаточно оптимизированы и мы часто наблюдаем производительность этих коллекций в пределах 0.4X от JVM.

Стоп, стоп, стоп. А какое же отношение может иметь производительность неизменяемых структур данных к JavaScript MVC? — Достаточно существенное.

Возможно, объяснить это будет не очень просто, но все же я постараюсь. Дело в том, что неизменяемые структуры данных, представленные в новой библиотеке Om позволяют создавать приложения на порядок производительнее, чем на популярных JS MVC фреймворков, таких как MVC Backbone.js (без ручной оптимизации). Om построен на прекрасном фреймворке от Facebook — React. Если вы не слышали о нём раньше, рекомендую посмотреть видео с JSConf EU 2013. Интересен тот факт, что из-за неизменяемых коллекций Om может продемонстрировать результаты лучше, чем при использовании React без каких-либо модификаций.

На Хабре уже разминались и развлекались кажущимися нелогичностями JavaScript. По-моему, такие примеры отличный способ размять мозги после длительных новогодних праздников, поэтому предлагаю вам подумать над 10 задачками.

Ответы и свой вариант объяснения почему такое поведение логично я буду скрывать под спойлером. Сразу оговорюсь, что не претендую на непоколебимую истину своих версий и буду рад их обсудить. В разгадывании вам может помочь отличный русский перевод спецификации ECMAScript 5 за который большое спасибо iliakan!

Gulp.js это потоковый сборщик проектов на JS. Он использует Stream и действительно является очень быстрым. Для примера у меня есть проект где около тысячи stylus файлов, GruntJS нужно примерно 2.5 секунды на сборку и 2 секунды на обработку autoprefixer'ом. Gulp все это делает за 0.5 секунды выигрывая у GruntJS минимум в 4 раза.



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

В этой статье будет больше практики, мы соберем среду разработки фронтенда используя Jade и Stylus, запустим локальный сервер и подключим Livereload. Проект я выложил на Github, экспериментируйте.

Предоставляю вам краткий отчет об изменениях в Impress AS за последние несколько месяцев. Во-первых мы не пошли путем фреймворков, а ринулись в сферу серверов приложений, обеспечивая масштабирование в двух направлениях: (1) много приложений на одном сервере и (2) много серверов для одного приложения. Первое направление требовало развивать сендбоксинг (экранирования приложений друг от друга и от среды запуска), а второе направление предусматривало переход от кластера к многосерверному клауду. Тут нужно уточнить терминологию, в ноде кластером (cluster) принято называть способ многопоточного запуска приложений в режиме master/worker, поэтому, многосерверную инфраструктуру (с кластером на каждом сервере) мы будем называть клаудом (или прикладным облаком). Это облако ни как не связано с виртуализацией операционной системы, как это обычно ложно связывается в понимании широких масс. Облачные технологии совсем не обязаны быть организованы на базе технологий виртуализации, но другого простого способа масштабирования сейчас для массового потребления нет. Облачная виртуализация не гарантирует бесконечной виртуализации прикладных приложений, и всем разработчикам крупных высоконагруженных систем известно, что для сотен тысяч и десятков миллионов пользователей нужно создавать специальные прикладные решения, обеспечивающие прикладную виртуализацию, размазывающую задачи по серверам и объединяю их в одну, распределенно функционирующую, но централизовано управляемую систему. Именно эту задачу мы и взялись решать в Impress, надеюсь я отстоял терминологию и могу переходить к подробностям.

Хотел бы поделиться небольшой заметкой о том, как ускорить выполнение $digest() путем замены стандартных директив эквивалентами, которые не вызывают $watch.

Одним вечером делать нечего, листая белые страницы интернета, в поисках чего бы такого мне почитать на сон грядущий, наткнулся я на одну занимательную статейку – на неизвестном мне ресурсе, от автора которого знать не знаю, слыхать не слыхал. Чтиво оказалось довольно интересным, с учетом того, что близко по роду деятельности, по форме и ее содержанию.

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

Естественно, что все ниже изложенное отнюдь не есть истина последней инстанции, как на библии, на ней клясться я бы не советовал. Но может быть кто-то откроет какие вещи с новой стороны, а кто – то покритикует, высказав свое ЧСВешное: «Фи фи фи, фа фа фа!».
Однако обо всем по порядку в моем своевольном от лица первого…

Проблема

Как обычно поздней ночью, садясь в автобус, я достал телефон, и пока набирал “habr…” он отрубился. Я вслух подумал: “А раньше не мог сказать?”, немного пожалел, что телефоны редко пищат, пока разряжаются. А потом…

Потом мы с приятелем решили подойти к вопросу по-мужски. Он написал программулину для андроида, а я расширил Хром. О последнем и пойдёт речь.

Задача

Итак, идея: андроид-приложение наблюдает за состоянием аккумулятора и периодически уведомляет сервер об уровне заряда. Причём делает это как-нибудь по-умному, чтобы заряд от этого не пострадал. Хром-расширение выставляет свою иконку в специально отведённом месте, иконка показывает заряд батарейки андроида и всячески привлекает внимание, если она совсем почти разряжена. А чтобы всё не казалось слишком простым, реализовать идею надо было за одни выходные. В противном случае баланс ценность/усилия вываливался за рамки бесплатного приложения.

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

На нашем проекте мы используем Backbone.js в качестве основного JS-фреймворка. Почему выбор пал на него, я возможно ещё расскажу в одном из следующих постов, в этот раз речь о другом. Как известно, из коробки Backbone предлагает весьма скромные возможности, компенсируя это максимальной гибкостью. Поскольку Backbone существует достаточно давно и успел обзавестись серьёзным сообществом разработчиков, для решения многих типовых задач Backbone-приложений сегодня существуют плагины либо целые надстроенные над Backbone фреймворки (многим известен например Backbone.Marionette, очень многообещающе выглядит недавно вышедший Base — кстати советую приглядеться).
Тем не менее, есть одна достаточно распространённая задача, адекватное решения которой мне до сих пор не попадалось: речь идёт о создании типовых автономных элементов UI. Скажем, у вас в проекте используется элемент выбора даты, для его создания вы используете найденный вами на бескрайних просторах гитхаба плагин jQuery. С этим последним всё хорошо кроме того, что вам нужно вручную дёргать его каждый раз, когда на вашей странице появляется соответствующий input, а потом возможно ещё и подчищать созданную им разметку во избежание дальнейших конфликтов. В итоге вам приходится писать много повторяющегося кода. Вот здесь вам и пригодится Backbone.Component.

Всем привет! Сегодня задача у нас следующая: необходимо создать интерфейс для загрузки картинок, который бы генерировал перед загрузкой превьюшки небольшого формата. На данный момент HTML5 вовсю шествует по планете, и, казалось бы, как это реализовать должно быть предельно ясно. Есть несколько русскоязычных статей на эту тему (вот, например). Но тут есть одно но. В рассматриваемом там подходе не уделено никакого внимания расходу памяти браузером. А расход может доходить до гигантских размеров. Разумеется, если загружать одновременно не более 5-10 картинок небольшого формата, то все остается в пределах нормы; но наш интерфейс должен позволять загружать сразу много изображений формата не меньше, чем у современных фотоаппаратов-мыльниц. И вот тогда-то свободная память начинает таять на глазах.