В настоящее в время существует огромное количество сетей распределенных вычислений. Я насчитал порядка 30. Наиболее крупные — Folding@home, BOINC, SETI@home, Einstein@Home, Rosetta@home (по результатам их вычислений было написано несколько десятков диссертаций). Вычисляют они все, что только можно вычислять распределено — от подбора md5 паролей до симуляции свертывания белка.
Каждая из эти сетей имеет необычно высокую производительность и включает в себя миллионы нодов. Производительность каждой сравнима с производительностью суперкомпьютера.

• Rosetta@home — более 110 Тфлопс
• Einstein@Home — более 355 Тфлопс
• SETI@home — более 560 Тфлопс
• BOINC — более 5.6 Пфлопс
• Folding@home — более 5.9 Пфлопс
• Bitcoin — более 9.4 Пфлопс

Сравните с суперкомпьютерами:

• Blue Gene/L (2006) — 478.2 Тфлопс
• Jaguar (суперкомпьютер) (2008) — 1.059 Пфлопс
• IBM Roadrunner (2008) — 1.042 Пфлопс
• Jaguar Cray XT5-HE (2009) — 1.759 Пфлопс
• Тяньхэ-1А (2010) — 2.507 Пфлопс
• IBM Sequoia (2012) — 20 Пфлопс

А теперь, давайте, подсчитаем существующий неиспользуемый потенциал пользователей интернет:
По расчетам на конец 2010 года пользователей Инернет было около 2000000000 (2 млрд).
Каждый пользователь имеет хотя бы 1 ядро процессора производительностью не менее 8 Гфлопс (AMD Athlon 64 2,211 ГГц).

По нехитрым математическим расчетам производительность такой сети составит:
8 * 109 * 2 * 109 = 16 эксафлопс (10¹⁸).
Такая сеть в 800 раз производительней, чем ещё не построенная IBM Sequoia (2012), в 1700 раз производительней, чем сеть Bitcoin и производительней всех суперкомьютеров и вычислительных сетей вместе взятых! Сейчас число пользователей ПК и Интерент растет, растет и число ядер. Безусловно, это число (16 эксафлопс) идеальное, никто не будет вычислять 24/7, но если каждый пользователь будет вычислять хотя бы 2 минуты в день (что, впринципе, более чем реально), то такая сеть сравнится с IBM Sequoia.

Сейчас распределенные браузерные вычислительные сети на JavaScript более чем реальны.

Всем привет. Данная статья посвящается методологии Разработки через тестирование (TDD) в применении c JavaScript.
Напишу лишь вкратце о методологии TDD, более подробную информацию можно почерпнуть из ссылки выше.

Разработка через тестирование подразумевает, что перед написанием кода необходимо:

• создать тест, который будет тестировать несуществующий код, тест соответственно не пройдет
• написать код и убедиться, что тест прошел
• почистить код
• повторить

Гибкость Javascript позволяет создавать объекты множеством способов. Но как это нередко случается, разнообразие таит в себе множество подводных камней. Из этой статьи Вы узнаете о том, как разглядеть и обогнуть эти опасные рифы.

13 мая компания CloudMade (со-основатель компании — основатель OpenStreetMap Стив Кост) объявила о новой open source JavaScript-библиотеке для любых карт под названием Leaflet.

Как написал Mourner (он же на Хабре — Mourner), автор этой библиотеки, живущий в Киеве (кстати, он будет рад услышать отзывы и ответить на ваши вопросы на форуме OpenStreetMap и здесь на Хабрахабре):

«Leaflet задумана как библиотека, одинаково хорошо работающая и на десктопных браузерах, и на мобильных устройствах (iPhone/iPad, Android) — очень быстрая, легковесная, с простым API, красивым и понятным ООП-кодом. В отличии от OpenLayers (самого популярного выбора на сегодняшний день) мы не пытаемся впихнуть в нее все фичи, о которых только можно помыслить, раздувая код до немыслимых размеров — только самое основное, минимальный набор, который удовлетворяет нужды 99% применений карт в онлайне (тайлы, маркеры, векторы, попапы), но реализовывая их максимально лучшим образом.»

Взаимодействие частей приложения друг с другом — важная часть архитектуры любой программы.
И существует немало паттернов для их реализации. Я бы хотел на примере веб-приложения показать применение одного из них, а именно — Event-driven модели.
Она хорошо известна любому frontend-разработчику — всякий раз, работая с событиями DOM, вы используете эту модель. Давайте попробуем построить на ней не маленькое веб-приложение — файловый менеджер.

Есть у меня старый сайт на Народ.Ру, и недавно я закинул туда несколько статей — как это я теперь делаю в UTF-8. Кодировка была указана в теге meta, но, взглянув на страницы, я увидел крякозябры: «Что-то случилось.» Оказывается, Народ.Ру шлёт HTTP-заголовок Content-Type: text/html; charset=windows-1251 и это на нём никак не отключается. Пользователь может получить читабельный текст — только если догадается вручную переключить кодировку в браузере.

Что делать? Переходить на другой хостинг? Само собой, но пока руки не дошли, хотелось добиться результата тут. Перекодировать тексты? Более достойным и интересным показалось поставить Javascript-«заплатку».

Способа переключить кодировку из Javascript я не нашёл. Остался вариант перекодировать текст скриптом, запускаемым по событию onready документа.

Итак, браузер получает текст в UTF-8, разбивает UTF-последовательности на группы по 8 бит и трактует их как коды символов в кодировке Windows-1251. Чтобы восстановить читаемость текста, нужно получить эти коды, объединить их в UTF-последовательности, а из них — восстановить Unicode-коды символов и вернуть последние посредством числовых ссылок HTML на символы. В этом деле обнаружились несколько закавык.

Backbone.js это каркас для создания RIA JavaScript приложений, его автором является Jeremy Ashkenas, создатель CoffeeScript, Backbone является частью компании Document Cloud ей же «принадлежит» Underscrore.js. Backbone — очень легкая библиотека, помогающая вам создавать интерфейсы. Она может работать с любыми библиотеками, к которым вы привыкли.

Backbone это набор классов, размером менее 4Кб, которые формируют структуру вашего кода и помогают создавать качественные MVC веб-приложения.

Backbone формирует структуру тяжелых JavaScript приложений, внесением моделей с key-value подобным хранилищем и своими событиями, коллекций с богатыми API, видов (ориг. views) с декларативной обработкой событий и соединяет все это в в одно приложение, поддерживающее RESTful JSON интерфейс.

Backbone не может работать без Underscore.js. Для поддержки REST API и работы с DOM элементами в Backbone.View настоятельно рекомендуется подключить json2.js и jQuery-подобную библиотеку: jQuery или Zepto

В статье будет рассмотрена структура Backbone.js, будет поэтапно создано простое Todo приложение.

От переводчика: В статье есть несколько JavaScript нюансов, которые могут быть интересны и тем, кто далек от CoffeeScript

Как и все программисты, я осторожен в отношение CoffeeScript. Как может, немного синтаксического сахара, оправдать дополнительный шаг компиляции?

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

В пятой редакции ECMAScript был представлен строгий режим (далее в статье Strict Mode). Strict Mode накладывает слой ограничений на JavaScript, он отгораживает вас от опасных частей языка (те части, которые есть исторически, но лучше чтобы их не было) и позволяет снизить вероятность ошибки.

Пока читал эту статью я написал 38 тестов, покрывающих все правила Strict Mode, объявленные в спецификации ES5. Вы можете посмотреть насколько ваш браузер поддерживает эти справила вот тут.



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

Firefox 4 уже полностью поддерживает Strict Mode, а Chrome 11 практически полностью. Strict Mode уже не за горами — давайте изучим его подробнее!

CANVAS шаг за шагом:

1. Основы
2. Изображения
3. Понг
4. Пятнашки

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

На днях вышел очередной релиз js-фреймворка для разработки веб-приложений QooxDoo. Одно из новых направлений развития фреймворка — разработка веб-приложений, работающих в мобильных браузерах. Большой размер собранного js, ориентация фреймворка на события мыши, особенности верстки делали работу с веб-приложением, написанным QooxDoo, в мобильных барузерах практически невозможной. В версии 1.4 разработчики фреймворка начинают экспериментировать с виджетами, элементами управления и темами, заточенными на особенности мобильных платформ. Кроме того в документации указано «Basic PhoneGap support» — т.е. веб-приложение, написанное на QooxDoo сможет быть собрано в мобильное приложение любой из используемых PhoneGap мобильных платформ.

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

Здесь можно посмотреть примеры приложений, собранных при помощи фреймворка (почтовые клиенты, системы управления личными финансами, тайм-менеджеры и т.д.), некоторые из которых — русскоязычные.

Прокси — это новые объекты JavaScript для которых программист должен определить своё поведение. Стандартное поведение всех объектов определено в движке JavaScript, который чаще всего написан на C++. Прокси позволяют программисту определить практически любое поведение объекта JavaScript, они полезны для написания базовых объектов или оберток функций или для создания абстракций виртуальных объектов и предоставляют API для мета-программирования. Сейчас Прокси не входит в стандарт, но его стандартизация запланирована в ECMAScript Harmony. Чтобы избежать путаницы уточню, что эти Прокси не имеют ничего общего с прокси серверами.

Где их можно использовать

1. Общие промежуточные абстракции
2. Создание виртуальных объектов: обертки существующих объектов, удаленные(от слова далекий) объекты, ленивое создание объектов (Пример ORM — Ruby ActiveRecord, Groovy GORM)
3. Прозрачное ведение логов, трассировки, профилирования
4. Внедрение предметно-ориентированных языков
5. Динамический перехват несуществующих методов, создание отсутствующих методов (__noSuchMethod__)
6. База для специфичных итераторов

Есть простейший с виду код:

setInterval(function(){
     var xhr = new XMLHttpRequest();
     xhr.open('GET', 'json.txt', true);
     xhr.onreadystatechange = function() {
        if(this.readyState == 4 && this.status == 200) {
           console.log(this.responseText);
        }
     };
     xhr.send('');
}, 500);

Если оставить этот код работающим в, например, Google Chorme, скажем, на 1 час, он съедает память. Съедает методично. Если посмотреть в Developer Tools на профиль использования памяти видно что память таки чистится GC но не до конца. Со временем минимальная точка на графике после GC растет.



Аналогично рост потребления памяти видно и по about:memory. «Отжир» памяти стабильно видно и в FF…

Важное...

• Файл json.txt лежит на localhost, его загрузка не занимает более 500мс гарантированно (я проверял).
• Вывод в консоль я тоже отключал — память по прежнему отжирается.
• EDIT без включенных developer tools — тоже течет, видно на about:memory.

Кроме этого кода более на данной странице никакого кода нет вообще.

Возможно я не понимаю как работает GC в JS, но по моему понятию тут нечему течь и нечему жить вечно. Может кто-то объяснить почему?

P.S. «Настоящей» утечки таки нет, если обновить страницу — память очищается.
P.P.S. Есть локальная жизненна потребность («требования бизнеса») оставлять подобный по структуре код на гораздо большие промежутки чем 1 час.

UPD: Оказывается есть даже тикет в хромиуме: code.google.com/p/chromium/issues/detail?id=52411
UPD: Якобы fixed in 9, но я проверяю на 10.

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

(function (foo, bar) {
	console.log(typeof arguments); // ?
	
	arguments[0] = 42;
	console.log(foo); // ?
})(10, 20);

А также покажу интересную идею-библиотеку

function test (foo, bar) {
    Args(arguments).defaults(100, 100);

    return [foo, bar];
};

test(      ); // 100, 100
test(15    ); //  15, 100
test(21, 42); //  21,  42

От переводчика: Я думаю многие читали статью Rey Bango — What to Read to Get Up to Speed in JavaScript, но до хабра обсуждение так и не докатилось. Предлагаю закрыть этот пробел и поговорить о хороших книгах, блогах, тренингах и конференциях, посвященных в первую очередь клиентскому JavaScript и клиентской веб-разработке. Чтобы не копипастить оформляю статью в виде перевода.

Сейчас в рассылке JSMentors JavaScript идет обсуждение книг, который стоит прочитать, чтобы улучшить свои знания. Там было много позитивных отзывов и предложений. Я хочу показать вам те книги и интернет-ресурсы, который я считаю важными и которые помогут вам в обучении. На этой странице я перечислил большое количество источников, разделенных по уровням.

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

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

В своём фреймворке AtomJS я активно использую аксессоры — геттеры и сеттеры:

Foo = atom.Class({
    get bar () {
        return this._bar;
    },
    set bar (bar) {
        this._bar = bar;
    }
});

Я уже описывал теорию, но в топике я расскажу о том, как заставить их работать во всех современных браузерах, а именно — как разрулить ситацию с тем, что Internet Explorer 9 ничего не знает о __defineSetter__ и подобных методах.

За нахождение хорошей фотографии спасибо ant99 а также фотографу.
Некоторое время назад я писал о том, как блокировать видимость в JavaScript с помощью конструкции let. Как оказалось из комментариев, let (как и JavaScript 1.7-1.8.5) поддерживается только браузерами на основе обезьянок и Rhino. Меня постигло разочарование, но минут 15 назад я придумал (хотя это громко сказано, наверное, и до меня было уже придумал кто-то) костыль для не такого красивого, но тем не менее рабочего кода. Он использует конструкцию with (да, я знаю, что она причислена к Bad Parts из-за ненужности и неэффективности, но вот прямо сейчас я опровергну первое утверждение).

Представьте, у вас есть проект, состоящий из нескольких модулей и, например, jQuery или любая другая библиотеки в CDN. У вас есть огромное желание не показывать пользователю ваши глобальные переменные и по возможности не показывать jQuery и $. Ну и, конечно, сделать все без изменения кода проекта.
Причины для сокрытия глобалов могут быть разные: для красоты, из соображений безопасности, для затруднения анализа кода и другие. Пользователь взаимодействует с вашим кодом, используя события, которые он не сможет сломать — больше ему ничего и не нужно.

Самый очевидный способ — создать единственный namespace в который пассивно экспортировать прочие объекты, а jQuery и $ в конце удалить.

После сборки код будет какой-то такой:

(function(window, undefined){
    // include ./js/YourNamespace.js
    var YourNamespace = (function () {
        // что-то ещё
        return {};
    }());
    // include ./js/YourNamespace/SomeObject.js
    YourNamespace.SomeObject = (function () {
        // что-то ещё
        return function () {

        };
    }());
    // Cleanup
    delete window.$;
    delete window.jQuery;
}(window));

Это идеальный вариант, но чаще бывает не так. Посмотрите ваш код, такой ли он?

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

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

Основы

Мы начнём с несложного обзора модульного подхода, хорошо известного с тех пор, как Эрик Миралья (Eric Miraglia) из YUI впервые об этом написал. Если вам уже знаком модульный подход, переходите сразу к «Продвинутым техникам».

Анонимные замыкания

Как гласит статья из Википедии, Песочница — механизм для безопасного исполнения программ. Песочницы часто используют для запуска непротестированного кода, непроверенного кода из неизвестных источников, а также для запуска и обнаружения вирусов.

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

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