JavaScript *

Предлагаем вашему вниманию подборку с ссылками на полезные ресурсы, интересные материалы и IT-новости

Доброго времени суток, решил расширить познания в js фреймворках, выбор пал на Meteor.JS, не зная с чего начать, стал гуглить. Нашёл хорошую статью на Хабре тут.



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

Такой движок JS, как V8 (Chrome, Node) от Google, заточен для быстрого исполнения больших приложений. Если вы во время разработки заботитесь об эффективном использовании памяти и быстродействии, вам необходимо знать кое-что о процессах, проходящих в движке JS браузера.

Что бы там ни было — V8, SpiderMonkey (Firefox), Carakan (Opera), Chakra (IE) или что-то ещё, знание внутренних процессов поможет вам оптимизировать работу ваших приложений. Но не призываю вас оптимизировать движок для одного браузера или движка – не делайте так.

Задайте себе вопрос:
— можно ли что-то в моём коде сделать более эффективным?
— какую оптимизацию проводят популярные движки JS?
— что движок не может компенсировать, и может ли сборка мусора подчистить всё так, как я от неё ожидаю?



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

Содержание:

• I. Перебор настоящих массивов
  
  1. Метод forEach и родственные методы
  2. Цикл for
  3. Правильное использование цикла for...in
  4. Цикл for...of (неявное использование итератора)
  5. Явное использование итератора
  
  
• II. Перебор массивоподобных объектов
  
  1. Использование способов перебора настоящих массивов
  2. Преобразование в настоящий массив
  3. Замечание по объектам среды исполнения
  
  

Привет, хабражители!

Представляю вам список YouTube-каналов для обучения веб-разработке. Список доступен на гитхабе, там он будет пополняться и редактироваться. В планах — создание отдельной странички для фильтрации каналов по тегам и рубрикам.

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

Под катом — текущая версия списка.

Элементарно! Но если бы мне показали подобную инструкцию раньше…

Задание

По запросу /profile без ключа отдаю шаблон login, если пользователь «не того», иначе отдаю шаблон на добавление newProfile или редактирование profile (editMode) своего профиля. А по запросу /profile/key отдаю шаблон на просмотр profile (not editMode) любого профиля; при этом userId не светится, и неверные ключи отвергаются на invalidProfile.

[исходник]

В виду отсутствия хорошего материала по парсингу с помощью скриптового браузера SlimerJS и наличия свободного времени решил написать небольшую статью.

Как известно, io.js ориентирован на новые версии движка V8, в которые включена поддержка стандарта ES6. В то время как в NodeJS для поддержки новых фич ES6 приходилось использовать флаг --harmony при запуске и другие заморочки, в io.js предусмотрены 3 группы новшеств:

• shipping — новшества, помеченные как stable в V8, такие как генераторы, шаблоны, новые строковые методы и т.д. Все они включены по умолчанию и не требуют специальных флагов при запуске
• staged — почти завершенные, но не оттестированные, либо не приведенные к стандарту ES6. Это новшества из разряда «используйте на свой страх и риск», которые требуют флаг запуска --es_staging (или --harmony)
• in progress — все остальные новшества, которые должны быть включены индивидуальным флагом (например --harmony_arrow_functions)

Обучающий материал с ресурса Phyramid, у которых именно такая шапка сайта.



Обновив в 2014 свой сайт, мы сделали трёхмерный фон в шапке, состоящий из геометрических фигур в 3D Max. Но потом мы подумали, что было бы гораздо круче генерить его в реальном времени на JS. Сказано – сделано, и при помощи замечательного фреймворка three.js мы сделали простенькую сценку. И вот, как это было.

Замечание по стилю кода: мы сначала хотели использовать только функциональный стиль, но из-за особенностей веба и работы алгоритма переключились на ООП.

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

Дело обстояло так: мы с моим старым другом уже не первый год занимаемся разработкой. Игра, о которой пойдет речь в статье, уже далеко не первая, которую мы пытались сделать, но первая, с которой это удалось. После почти десятка неудавшихся попыток сделать игру мы наконец-то смогли объективно оценить свои силы и решили сделать головоломку. Жанр игр сам по себе несложный, но то, что мы задумали, было куда сложнее и не похоже ни на одну из игр, представленных в каталогах ВК и ФБ в этом жанре. Для того, чтобы совсем не осталось шансов закончить игру, решили использовать те технологии, которые никогда в глаза не видели — Dart + Box2d.

Наглядный пример задачи — сайт vk.com. Каждый раз, когда вы воспроизводите музыку или видео в одной вкладке, в других вкладках воспроизведение останавливается. И если вы обратитесь в интернет за помощью в решении данной задачи, то наверняка найдете описание Storage Events или Page Visibility API или даже готовые решения, к примеру Visibility.js.

На хабре уже был обзор этих вещей, к примеру вот и ещё.



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

Простой диспетчер задач с веб-интерфейсом, написанный на языке GO для Unix-систем включая Android.

Ни для кого не секрет, что Google повсюду в своих продуктах внедряет так называемый material design. Как и любой другой стиль он имеет сторонников и противников. Не буду касаться этих споров. Если вам нравится данный подход, Google подготовил полную спецификацию и описание особенностей: Material Design.

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

Я постараюсь кратко показать некоторые особенности и недостатки, а также покажу небольшое приложение для демонстрации.

Это не первая вводная статья про Impress на Хабре, но за последний год я получил много вопросов и приобрел некоторый опыт в объяснении архитектуры и философии этого сервера приложений и, надеюсь, стал лучше понимать проблемы и задачи разработчиков, начинающих его освоение. Да и в самом сервере произошло достаточно изменений, чтобы назрела актуальность совершенно новой вводной статьи.

Impress Application Server (IAS) — это сервер приложений для Node.js с альтернативной архитектурой и философией, не похожий на мэйнстрим разработки под нодой и призванный упростить и автоматизировать широкий круг повторяемых типовых задач, поднять уровень абстракции прикладного кода, задать рамки и структуру приложений, оптимизировать как производительность кода, так и производительность разработчиков. IAS покрывает сейчас только серверные задачи, но делает это комплексно, например, можно объединить на одном порту API, веб-сокеты, стриминг, статику, Server-Sent Events, проксирование и URL-реврайтинг, обслуживать несколько доменов и несколько приложений, как на одном сервере, так и на группе серверов, работающих в связке, как одно целое, как один сервер приложений.

Предлагаем вашему вниманию подборку с ссылками на полезные ресурсы, интересные материалы и IT-новости

Доброго времени суток, уважаемые хабравчане. Поздравляю всех с наступившим 2015 годом! За последнее время я увидел несколько интересных и полезных инструментов/библиотек/событий, которыми хочу поделиться с Хабром.

Лучшее от Codrops за 2014 год

Я думаю многие из вас знакомы с потрясающими демками от Codrops. Авторы сайта буквально всегда реализуют интереснейшие UI/UX задумки с помощью HTML/CSS/SVG/JS и подробно рассказывают о том, как они это сделали. А это их собственная мега подборка с лучшими работам. Также рекомендую для вдохновения коллекцию самых популярных пэнов за 2014 год от CodePen.

В посте про «Звездное небо на Canvas» я уже описывал свой проект, где при помощи JavaScript на канвасе 2d формируется изображение глобуса Земли на фоне звезд, планет и орбит космических аппаратов. Для создания трехмерной картины звездного неба на плоскости я использовал формулы перевода трехмерных координат X, Y, Z отображаемых объектов: звезд, планет, космических аппаратов (КА), — в плоские декартовые координаты X, Y. Основную часть этих формул я взял из проекта Marble из состава KDE. Портированный с C++ на JavaScript код я сохранил в файле starry.js.

Не все JSON нельзя комментировать (например, Хром[иум] вполне переносит комментарии в manifest.json), но в стандарте не предусмотрены комментарии к нему. Поэтому ряд функций в NodeJS не обрабатывают комментарии в формате JS и считают их ошибкой. Точно так же, AJAX с форматом JSON принимает их за ошибку. Поэтому для конфигурационных файлов в формате JSON имеется масса неудобств при попытках их использовать как человеко-читаемые файлы. Может быть, это иногда хорошо. Если хотим прокомментировать, то будем вынуждены оформить комментарий под или над строкой как «ключ-значение».

...{...
    "some-key_comment":"my comment for key and value",
    "some-key":"some-value",
...}...

Но если комментарии не пишем, следуя суровости протоколов, ошибки возникают уже из-за другого фактора — забывания смысла параметров настроек при редактировании человеком.

...{...
    "some-key":"some-value", //какой-какой key?? Ай, комментарии - нельзя!
...}...

Придумаем JSON-подобный формат с комментариями в стиле JS, чтобы их можно было выполнять как JS, а, очистив от комментариев — читать как JSON. ("TL:DR: покажите мне код.")

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

var A = {
    doStuff (){}
}

var B = {
    doStuff (){}
}

var C = React.createClass({
    mixins: [A, B]
});
//упс... ошибка, потому что React не может решить какой из doStuff унаследовать

В JavaScript существует множество разных способов наследования, классового и прототипного, фабричного и через примеси, прямого и непрямого, а так же гибриды нескольких методов. Но у Node.js есть его родной способ с применением util.inherits(ChildClass, ParentClass). До недавнего времени я использовал нодовский способ только для встроенных классов (когда нужно сделать своего наследника для EventEmitter, Readable/Writable Stream, Domain, Buffer и т.д.), а для моделирования предметной области применял общеупотребительные для всего JavaScript практики. И вот, впервые, понадобилось реализовать собственную иерархию системных классов, не наследников от встроенных, но и не классов предметной области, а классов, массово поражаемых в системном коде сервера приложений Impress. И простого использования util.inherits уже как-то не хватило, поискал я статьи и не найдя полностью всего, что мне нужно, изучил примеры наследования в исходниках самой ноды, подумал и сделал пример родного нодовского наследования себе на память и написал эту небольшую заметку, чтобы она, надеюсь, помогла еще и вам. Сразу предупреждаю, что реализация вызова метода родительского класса из переопределенного в дочернем классе метода, мне не очень нравится из-за громоздкости, поэтому, приветствую альтернативные способы и приглашаю коммитить их в репозиторий или в комментарии к этой заметке.