Если Вы программируете на node.js, но устали писать роутинг запросов в коде, у Вас нет предубеждения против использования глобальных переменных в служебных целях и Вы согласны, что излишняя свобода губительна для масс, то тоталитарный кружок выходного дня приготовил для Вас прототип альтернативной платформы для разработки веб приложений. Предупреждаю, что тоталитарный стиль предполагает не встраивание фреймворка в приложение через require, а наоборот, встраивание своего приложения в структуру фреймворка, где фрагменты кода приложения будут на каждом шагу иметь дело с дополнительными ограничениями и навязанными структурами кода и данных. Про то, что «less-than-expert» смогут разрабатывать высокопроизводительные системы, как утверждают разработчики ноды — ну тут Вы сами понимаете, что это будут за системы, особливо асинхронные, с потерянными коллбеками и утечками памяти на каждом шагу. В плане защиты от дурака, сей прототип чудес не доставляет. И конечно же, ожидаю от Вас много конструктивной критики, потому, что прототип сырой, хоть и собрал в себе множество концептуальных наработок нашей команды за последнее десятилетие. Даже название Impress появилось всего два дня назад и, да — это самый сложный вопрос.

Документация по Ангуляру отлично подходит для начала работы и ковыряния в API. Однако, она не объясняет как организовать и управлять приложением, когда оно разрастется до десятков или сотен тысяч строк кода. Я собрал здесь некоторые из моих наблюдений и передового опыта по управлению расползающимися приложениями. Сначала взглянем на организацию, затем перейдем к некоторым советам по улучшению производительности и закончим краткой сводкой по инструментам, серверам и процессу сборки. Этот пост будет сосредоточен на больших приложениях, в частности, есть отличная статья по лучшим практикам AngularJS с декабрьской встречи, на которую также стоит взглянуть.

На момент написания этой статьи в JavaScript еще не существовало официальной модульной системы и все эмулировали модули как могли.

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

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

Дело в том, что раньше не думали, что на JavaScript можно делать огромные проекты, а не просто «пропатчить DOM», поэтому о модулях не думали. Да и вообще не думали о будущем. И тут Внезапно будущее нагрянуло! Все вроде-бы уже есть, а модули в JavaScript, мягко говоря, запаздывают. Поэтому разработчикам приходится крутиться и выдумывать какие-то эмуляторы модульности.

Думаю многие из вас читали прекрасную статью Addy Osmani Writing Modular JavaScript With AMD, CommonJS & ES Harmony, которая стала одной из глав его книги Learning JavaScript Design Patterns в этой статье рассказывается про «современные» JavaScript модули или же читали достаточно старую статью JavaScript Module Pattern: In-Depth 2010 года про «старые» модули.

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

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

Вас ждет много анализа и немного частных производных. Код прилагается.
Прошу под кат!

Разрабатывая MaskJS вот уже больше полугода, удалось превратить DOM шаблонизатор в очень мощный, но при этом производительный веб фреймворк. В статье познакомлю вас с возможно интересными подходами к разработки. Уверен, будет интересно почитать о использовании сигналов и слотов вместо DOM событий. И как компоненты делают нашу жизнь проще. Маска легко интегрируется в уже готовый проект, и даже может быть использована вместе с любым другим фреймворком. Основным же отличием наверное является render flow, где в процессе поэтапно создается Document Fragment / контроллеры / «биндинги». Собственно всю гибкость даже сложно передать, но я попробую, и приглашаю под кат.

Давным давно в результатах поиска в Google Search слева было меню, где одним кликом можно было настроить параметры поиска, например ограничение по времени (этой возможностью я часто пользовался). Но при редизайне — почему-то это начало требовать 3 клика:



Надеяться на то, что Google одумается не приходится — остается взять дело в свои руки. Пока userscripts.org что-то глючит, скрипт можно скачать тут, жмите на кнопку Raw.

Firefox — ставится с помощью Scriptish/GreaseMonkey (аддоны для скриптов);
Chrome — непосредственно, без расширений (скрипт в виде файла затаскивается на страницу chrome://extensions/);
Opera — создаётся юзерскрипт в файле, помещается в папку… ( инструкция);
Safari — ставится с помощью NinjaKit (не проверялось, но ничего особого в скрипте нет).

Chrome Logger это Google Chrome расширение для отладки серверсайд приложений в консоли хрома.

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

Инструкции по применению инсайд.

Хочу предоставить вашему вниманию библиотеку 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'));
});

Благодарю всех кто прочитал, отозвался и оценил первый пост!

Для демонстрации как работает идеология Jiant — реализовал ToDoMVC, проект, созданный для оценки различных MVC фреймворков. Jiant не MVC фреймворк, а скорее подход к разработке с набором вспомогательных инструментов. На разработку у меня ушло порядка 8 часов с учетом чтения и понимания спецификации, изучения референтной реализации, localStorage, с которым не имел дела (очень простая штука) ну и всего прочего. Не знаю много это или мало, но вот столько. Результаты лежат по адресу: github.com/vecnas/todomvc-jiant. В Chrome и Firefox работает прямо с файловой системы, в IE — с сервера.

Здравствуйте всем, этот пост о библиотеке, а вернее философии разработки приложений на Javascript которую изобрел пару месяцев назад. Постоянно использую сам, раздал всем друзьям. Отзывы положительные, поэтому решил рискнуть открыть более широкому сообществу.
Сама библиотека работает как подстройка к jQuery. Практически зависимость от jQuery условна и ее можно разделить с самой библиотекой, пока не было необходимости.
Jiant позволяет создавать клиентские приложения любой сложности, значительно упрощая их поддержку и развитие.

Большинство современных языков программирования позволяют использовать асинхронно выполняемые блоки кода. Вместе с гибкостью, получаемой при использовании асинхронного подхода, рискнувший его применить также получает более сложный для понимания и поддержки код. Однако, любое усложнение, с которым сталкиваются программисты, как правило, находит практическое решение в виде нового подхода или повышения уровня абстракции. В случае асинхронного программирования таким средством служит объект типа отложенный результат или deferred (англ. deferred — отложенный, отсроченный).

В статье будет рассказано о базовых подходах к возврату асинхронных результатов, функциях обратного вызова, объектах deferred и их возможностях. Будут приведены примеры на языке JavaScript, а также произведён разбор типового объекта deferred. Статья будет полезна программистам, начинающим постигать асинхронное программирование, а также знакомым с ним, но не владеющим объектом deferred.

Предисловие от переводчика.  В постскриптуме к моей вчерашней блогозаписи я указал, что AppJS — это не единственное такое средство, которое позволяет создавать приложения с GUI (графическим интерфейсом пользователя) при помощи вебоподобных методов разработки на языках HTML, CSS и JavaScript с использованием движка Node.js. Естественной иллюстрацией к этому постскриптуму является нижеследующий перевод гитхабовской страницы проекта node-webkit. И сразу скажу: я предвижу заранее, что непредвзятый взгляд ваш сочтёт node-webkit ещё более удобным и развитым средством, чем AppJS.

---

Введение

node-webkit — среда для запуска приложений, основанная на Chromium и Node.js. При помощи node-webkit можно создавать традиционные графические приложения посредством HTML и JavaScript. Также node-webkit позволяет вызывать модули Node.js прямо из DOM и тем обеспечивает новый способ создания таких приложений и употребления веботехнологий в них.

node-webkit создан и разрабатывается в Интеловском Центре технологий с открытым исходным кодом (Intel Open Source Technology Center).

Введение в node-webkit (слайды).

Достоинства

• Приложения создаются при помощи современных HTML5, CSS3, JS и WebGL.
   
• Полная поддержка API Node.js и созданных другими разработчиками модулей.
   
• Вызов API Node.js без потерь в производительности.
   
• Лёгкость упаковки и распространения приложений.

В первой части статьи я рассказал о некоторых концептуальных провалах Facebook в области юзабилити. Сейчас я вооружился карандашом и бумагой и поставил перед собой такую вот задачу: если бы я был проектировщиком Facebook и мог бы сделать “все хорошо”, то с чего бы я начал?

В данной статье будет рассмотрена одна из новых возможностей MongoDB версии 2.4 — полнотекстовый поиск. Большая часть этой статьи будет вольным переводом документации, которая, к слову, очень подробная, но разрозненная. Здесь все будет собрано вместе. Так как этого для полноценной статьи мне показалось мало, я решил сравнить МонгоДБ с другой популярной программой для текстового поиска — Sphinx. Мое сравнение будет очень поверхностным, так как со Сфинксом я раньше не работал. Создам таблицу с 16 000 000 записей и посмотрю, кто быстрее.

Pixi.js позволяет использовать мощь WebGL для рендеринга 2D-сцен, совершенно не вникая в подробности реализации, более того, он умеет самостоятельно определять наличие поддержки WebGL и переключаться между способами рендеринга. В отсутствие WebGL рендеринг осуществляется средствами canvas. Кроме того в Pixi.js реализован граф сцены, поддержка текстур и спрайтов, чуть больше недели назад в нём появилась поддержка интерактивности — на спрайты можно повесить обработчики событий мыши и тачскрина.

Введение

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

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

С каждым днем сайты становятся все сложнее и динамичнее. Уже недостаточно просто «оживить» интерфейс — все чаще требуется создать полноценное одностраничное приложение. Ярким примером такого приложения является любая web-почта (например, Mail.Ru), где переходы по ссылкам приводят не к перезагрузке страницы, а только к смене представления. А это значит, что задача получения данных и их отображения в зависимости от маршрута, которая всегда была прерогативой сервера, ложится на клиент. Обычно эту проблему решают с помощью простенького роутера, на основе регулярных выражений, и дальше не развивают, в то время как на back-end этой теме уделяют гораздо больше внимания. В этой статье я постараюсь восполнить этот пробел.

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

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

Я обожаю twitter bootstrap. Прост, местами логичен, достаточно красив, подходит для быстрого прототипирования веб-интерфейсов. Но этого оказалось недостаточно. Взяв twitter bootstrap в большой проект, мне пришлось целиком его разобрать и переосмыслить css-фреймворки как боевые единицы в веб-проектах. В результате переосмысления родились требования к любому css-фреймворку, удобному как верстальщику, так и frontent-разработчику.

TL;DR
Эта обзорная статья. Такое себе "краткое содержание предыдущих серий". Она будет полезна для новичков, или тех, кто не следил за отраслью в последнее время. Для новичков это будет первый шаг во "Вселенную JavaScript", бывалые смогут освежить свои знания.

У JavaScript очень удивительная судьба. Он преодолел путь от самого не понимаемого до самого удивительного языка. У него было тяжелое детство:
Изначально Автор хотел написать функциональный язык. Но менеджеры хотели получить, «обычный» объектно-ориентированный. И чтобы было легко искать разработчиков для новоиспеченного языка синтаксис решили сделать похожим на Java и даже название сделали похожим.
Но на этом история не заканчивается. Java, JavaScript это торговые марки Sun (а теперь Oracle). Microsoft не мог воспользоваться именем JavaScript (Netcape и Sun дружили против Microsoft). В результате Microsoft решил сделать реверс инжиниринг JavaScript и назвал его JScript. Сделали реверс инжиниринг, и сделали его настолько хорошо, что даже содрали все баги в реализации. Позже решили сделать стандарт и назвали его ECMAScript.