JavaScript *

Будучи поклонником программных продуктов для визуализации активности в репозиториях таких как code_swarm и gource. В один прекрасный день я был посещен музой, которая вдохновила меня создать онлайн сервис для визуализации статистики репозиториев с GitHub.
И сегодня хочу предоставить на ваш суд мой проект GitHub Visualizer (проект на GitHub).
Вот скринкаст для предварительного знакомства.

И не большая Gif'ка

Что использовано

• SVG, Canvas — для интерактивной графики.
• D3.js — javascript библиотека позволяет очень удобно работать с данными и визуализировать их.
  Гигантская коллекция примеров от автора библиотеки Mike Bostock.
• API GitHub

Сегодня Mozilla совместно с игровой студией Epic Games выступила с инициативой создания визуально привлекательных 3D-игр, которые не должны уступать декстопным аналогам, и выполняться прямо в браузере.

Фактически речь идёт о том, чтобы перенести в веб опыт создания качественных, требующих высокой производительности, игровых приложений, которые должны будут выполняться обновленным движком JavaScript OdinMonkey, который недавно был включён в ночные сборки FireFox и скорость выполнения кода на Asm.js которым в 10 раз превышает аналогичный в других браузерах. Причём это всё без сторонних плагинов вроде Flash или Silverlight — чистый JavaScript.

Тот визуальный опыт, который должен получить геймер в интернете, играя в 3D-игру, предлагается оценить на видео ниже — так выглядит порт Unreal Engine 3, сделанный инженерами Epic Games и Mozilla:

FightCode — это онлайн-игра для программистов, построенная по образу и подобию классической Robocode. Для программирования танков используется JavaScript, все сражения происходят прямо в браузере, а редактор кода на сайте имеет встроенную «песочницу», которая позволяет в реальном времени видеть эффект от изменений кода. В отличие от многих других подобных игр, создатели неплохо поработали над дизайном — игровое поле и весь сайт в целом выглядят привлекательно и ярко.



Всё это делает FightCode одним из лучших вариантов для новичков в подобных играх или для обучения программированию. Проект довольно молодой, и несмотря на то, что на сайте зарегистрировано почти 9000 игроков, пробиться в первую сотню рейтинга можно без особых усилий. Очень удобно организована система боёв со случайными соперниками — из всех доступных роботов автоматически выбираются те, чей рейтинг близок к вашему. Очки считаются по системе Эло — победа над более сильным противником даёт гораздо больше очков, чем над слабым.

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

У многих соц.сетей и сообществ существуют примеры использования букмарклетов (bookmarklet) для шаринга ссылок, картинок и т.п. из броузера. Мне кажется это удобным, если вы любите часто делиться контентом через соц.сети. Например, чтобы поделиться открытой в окне броузера фоткой или картинкой достаточно воспользоваться букмарклетом, вместо того, чтобы копировать адрес фотки, открывать страницу соц.сети и там как-то шарить ссылку.
У FB, VK, LJ и прочих примеры букмарклетов есть обычно в разделе помощи. У Одноклассников (odnoklassniki.ru) нет ни примера на сайте сети, ни примеров вообще в гугле. То ли никому эта сеть не нужна, то ли никто не пользуется букмарклетами для шаринга контента.
Т.к. в сети не нашёл ни одного примера букмарклета, решил поделиться своей поделкой (взял букмарклет для FB и переделал его под Одноклассники).

Хочу предоставить вашему вниманию библиотеку Vow, которую написал мой коллега Дмитрий Филатов dfilatov.

Библиотека реализует Promises/A+, работает очень быстро и требует малого объема памяти. По тестам производительности сильно опережает Q, но при этом сохраняет асинхронную манеру работы.

Работа с Vow выглядит так же просто, как работа с Q. Из недостатков (по сравнению с Q) можно лишь выделить отсутствие progress.

Пример кода с использованием Vow:

function readFile(filename, encoding) {
    var promise = Vow.promise();
    fs.readFile(filename, encoding, function(err, data) {
        if (err) return promise.reject(err);
        promise.fulfill(data);
    });
    return promise;
}
Vow.all([readFile('test1.txt', 'utf8'), readFile('test2.txt', 'utf8')]).then(function(results) {
    console.log(results.join('\n'));
});

Заметил, что на Хабре никто не писал про отличный JavaScript шаблонизатор Swig.

JavaScript в поледнее время становится все более популярным и находит новые неожиданные сферы применения. Вот и меня не обошел этот тренд, так что при just-for-fun разработке одного проекта я не удержался и решил попробовать использовать JS одновременно на сервере (Node.JS), веб-клиенте (Backbone.js — все серьезно :) ) и в мобильном приложении (PhoneGap). Следующим шагом для меня стал выбор шаблонизатора, причем поддержка как node, так и браузера была обязательным критерием. До этого я имел дело в основном в Django Template Language, так что выбор пал на Swig.

Особенности Swig:

• Django Template подобный синтаксис
• Крайне высокая скорость работы (бенчмарки)
• Поддержка node.js и основных браузеров
• Совместимость с Express
• Открытый исходный код

Здравствуйте, хабражители!

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



А что из этого получилось — под катом.

Модуль OdinMonkey — часть движка IonMonkey, отвечающая за оптимизацию и компиляцию низкоуровневого Asm.js — 21 марта был включён в состав сборки Firefox Nightly. Что такое Asm.js? — это подмножество языка JavaScript, позволяющее программировать «на уровне ассемблера» — без динамической типизации и выделения памяти. В каком-то смысле Asm.js аналогичен технологии Google Native Client, только с обратной совместимостью — код, написанный по спецификации Asm.js, является корректным кодом JavaScript и будет выполняться на любом движке, только медленнее, чем при наличии OdinMonkey.

Asm.js позволяет в ряде случаев вплотную приблизиться к производительности нативного кода — программа на Си, скомпилированная в Asm.js, обычно работает всего вдвое медленнее оригинала:

Расскажу об особенностях с которыми я столкнулся при сохранении изображения из canvas в GIF.
Тут будут рассмотрены готовые решения и мой собственный javascript код квантизации изображения (то есть уменьшение палитры до 256 цветов). Так же будут затронуты вопросы быстродействия некоторых javascript конструкций.

Вот JavaScript-овый объект, сериализованный в JSon:

var source1 = '[{"vConfig":{"vType":"objectview","serverItemType":"TrackerObject"}}]';

А вот ещё один JavaScript-овый объект, тоже сериализованный в JSon:

var source2 = '[{"vConfig":{"serverItemType":"TrackerObject","vType":"objectview"}}]';

У них одинаковая структура, одинаковые параметры, одинаковые значения в этих параметрах. По всем признакам, и в source1, и в source2 у нас одно и то же.

Но интерпретатор JavaScript с нами, разумеется, не согласен. И он вполне резонно считает, что source1 и source2 — разные строки. А если мы десериализуем их обратно, то получим два object-а, которые расположены по различным адресам памяти и… тоже не равны друг другу.

А если вы, впридачу, работает с Ext.js, щедро генерируете свои классы и не забываете про jSon, то может дойти до полного затмения. Как сравнить эти огромные простыни сведений о контролах, которые собираются в JSon-ы? Или разобраться древовидными объектами, где в каждое поле уже успели насоздаваться ещё какие-то подполя?

Заранее прошу прощения за некоторые обороты в переводе. Буду рад услышать здравую критику и поправки, лучше в пм. Спасибо. – пер.

Стартапы имеют много общего с JavaScript'ом. Когда вы только начинаете, вам нужно быть динамичными. Вы должны быть гибкими. Вы должны иметь возможность мгновенно выпустить прототип, который просто работает, и вам нужно уметь быстро и дешево менять его без перекомпиляции вашего кода. JavaScript появился когда война между браузерами только начиналась, и он раздавил Java и Flash по тем же причинам, по которым стартапы рушат рынки и вытесняют признанных игроков: быстрота и гибкость.

Если вы еще не в курсе: JavaScript победил. На сегодняшний день это самый кроссплатформенный язык, доступный для любых устройств. На нем можно создавать веб-приложения (клиент и сервер), в том числе с оффлайн-режимом работы, десктопные приложения (для Windows 8), приложения для смартфонов и планшетов (PhoneGap), расширения для Microsoft Office, SharePoint и Dynamics. Код на JavaScript работает в СУБД, таких как MongoDB и даже Hadoop в Windows Azure (BigData однако).

На Javascript уже написаны Doom и эмулятор Linux. Фактически решая любую задачу, кроме написания модуля ядра ОС, вы встретитесь с JavaScript. Если вы еще не знаете JavaScript, то вам следует срочно начать его изучать.

Не так давно я обнаружил, что JavaScript позволяет изменить атрибут href тега <a> после того, как вы щелкнете по нему. На первый взгляд это выглядит несерьезно, но не сомневайтесь — таким способом злоумышленник сможет получить данные пользователя.

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

Как вы убедились, вы не перешли на PayPal (кроме Opera, где, по-видимому, это поведение исправлено). Так произошло потому, что после нажатия на ссылку был запущен код, который изменил атрибут href ссылки, и что удивительно — браузер отправляет по-новому адресу. Но так не должно происходить. Посетители сайта (пожалуй, самые технически подкованные их них) по ссылке будут предполагать куда они переходят, в данном случае, на сайт PayPal. В прошлом году PayPal в течение нескольких месяцев производил редирект с главной страницы (UK) на paypal-business.co.uk. По моему мнению, пользователи уже привыкли к таким перенаправлениям, что уже само по себе является уязвимостью и представляет реальную угрозу, как я её называю «Фишинг 2.0».

Если кто-то ещё не знает, что такое хвостовая рекурсия, вот простой пример метода, складывающего в лоб натуральные числа от 1 до n (n≥0):

function add(n,acc) {
  if(n===0) return acc;
  return add(n-1,acc+n);
}

Изначально функция вызывается с параметром acc=0. В случае, если n не равно нулю, метод вызывает сам себя с другими параметрами и возвращает результат. Компилятор (или интерпретатор, или виртуальная машина) могут понять, что текущий вызов функции в стеке уже не нужен, стереть его и заменить следующим вызовом. Таким образом, рекурсия не приводит к разрастанию стека. Строго говоря, хвостовой вызов не обязан обращаться к текущей функции: вызов любой другой тоже может быть хвостовым. Главное условие: вызов функции и возврат её результата должны быть последними действиями в текущей функции. К примеру, в такой реализации метода хвостовой рекурсии нет, так как после вызова происходит ещё сложение:

function add(n) {
  if(n===0) return 0;
  return n+add(n-1);
}

По ряду причин хвостовая рекурсия в JavaScript не поддерживается (обсуждение на эту тему есть на StackOverflow). Поэтому вызов вроде add(100000,0) завершится исключением. На Хабре предпринимались попытки решить эту проблему через setTimeout, но это выглядит не очень честно и не очень красиво. Более изящное решение для языка Python было предложено с использованием «трамплина». Похожий подход для JavaScript рассмотрен здесь. Но мне захотелось, чтобы работало быстро и чтобы функцию можно было записать прямо как в примере выше. Посмотрим, что можно сделать.

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

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

Сперва, небольшой эксперимент

Чтобы сделать эту небольшую статью намного интереснее, я предлагаю просто открыть результаты поиска Google и сразу вернуться к чтению под катом.

Часть 1

В данной статье мы рассмотрим базовые понятия событийной модели StateController'а.

Зоны распространения событий

В селективной модели приложений работа ведется с теми элементами, которые были предварительно выбраны для работы. В чистой событийной модели событие должно распространяться на все элементы DOM-дерева. Это совершенно не важно на маленьких объемах, но при росте количества нод деградация скорости будет даже не линейной. Представьте себе, что событие click должно пройтись по всем нодам, чтобы определить, на каких именно элементах оно сработает. Есть предположение, что псевдокласс :hover в IE6 именно так и работал, поэтому он так сильно тормозил.

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

Введение

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

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

Введение

Приветствую вас, хабравчане. В данном топике я хотел бы осветить подробности разработки на C# под разнородные целевые платформы, в первую очередь такие как .NET и браузер (JavaScript). В качестве примера желающие могут изучить веб-сервис по обработке фотографий gfranq.com, в котором реализована клиентская и серверная обработка фотографий с помощью фильтров, а также функциональность коллажей на основе материала, описанного в данной статье.

Так как я не умею подбирать картинки для привлечения внимания, то она будет по теме:

AngularJS — прекрасный фреймворк для построения веб-приложений. У него замечательная документация, снабженная примерами. В обучающих «пробных» приложениях (вроде TodoMVC Project) он очень достойно показывает себя среди остальных прочих фреймворков. По нему есть отличные презентации и скринкасты.

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