Реставрация старых игр

Привет Хабра! Это статья первая из цикла статей о игровом движке StalinGrad. Начну повесть о нем из далека, рассмотрев предпосылки для его создания. В статье речь пойдет о том, как делать игры, конвертировать JS -> APK, и прочих трудностях и проблемах.

Пример до реставрации и после (а еще для Android`a):

Разработчиков COLT постоянно спрашивают в чем разница между Bracket/Adobe Adge и COLT.

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

Спасибо!

Независимо от того насколько большая ваша любовь к командной строке, согласитесь, что простой и удобный интерфейс консоли, поддержка истории, авто дополнение, простые команды весьма впечатляют. Не вдаваясь в дисскусию о преимуществах и недостатках «темноты», хочу представить на суд Хабра-сообщества свою маленькую поделку из мира Node.js, главной задачей которой является улучшение жизни разработчика, который решился написать консольную утилиту.

Cline — обзор

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

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

От переводчика: Это четвёртая статья из цикла о Node.js от команды Mozilla Identity, которая занимается проектом Persona. Эта статья о том, как увеличить скорость загрузки ресурсов сайта и модуле connect-cachify, созданном в Mozilla для этой цели.

Все статьи цикла:

1. "Охотимся за утечками памяти в Node.js"
2. "Нагружаем Node под завязку"
3. "Храним сессии на клиенте, чтобы упростить масштабирование приложения"
4. "Производительность фронтэнда. Часть 1 — конкатенация, компрессия, кэширование"
5. "Пишем сервер, который не падает под нагрузкой"
6. "Производительность фронтэнда. Часть 2 — кешируем динамический контент с помощью etagify"
7. "Приручаем конфигурации веб-приложений с помощью node-convict"
8. "Производительность фронтенда. Часть 3 — оптимизация шрифтов"
9. "Локализация приложений Node.js. Часть 1"
10. "Локализация приложений Node.js. Часть 2: инструментарий и процесс"
11. "Локализация приложений Node.js. Часть 3: локализация в действии"
12. "Awsbox — PaaS-инфраструктура для развёртывания приложений Node.js в облаке Amazon"

---

В этой статье мы поговорим о производительности фронтэнда и представим инструменты, созданные в Mozilla для того, чтобы сделать сайт Persona настолько быстрым, насколько возможно. Мы опишем работу с connect-cachify — модулем, автоматизирующим некоторые из важнейших аспектов, обеспечивающих производительность фронтэнда.

Но сначала окинем взглядом наиболее распространённые пути улучшения производительности. Если у вас уже есть опыт оптимизации фронтэнда, можете пропустить эти разделы и перейти в конец статьи, где описано, как с помощью connect-cachify автоматически делать то, что вам раньше доводилось делать вручную.

Сегодня мы сделали демонстрацию ливкодинга HTML-страницы сразу же на нескольких устройствах и браузерах.
В демонстрации участвовало три ноутбука (sаfari, firefox, chrome), один телевизор (Samsung c Smart Hub), один iPad 3, и iPhone 4 и страница Apple iPhone 5C.

Представляю вам бандл библиотек для создания web-документов с использованием разметки Markdown.
Сразу хочу сказать, библиотек такого направления в сети много, но эта имеет принципиальные отличия и обладает большим функционалом по сравнению с ними. Что называется powered by.
Это рассказ о прототипе и полной документации еще нет. Возможны (и нужны) изменения в коде и архитектуре библиотеки, но язык разметки и шаблон страницы уже практически стабильны.

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

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

Это открытое письмо CoffeeScript-сообществу.
Вы можете присоединиться к дискуссии на Hacker News.

Эта тирада, возможно, также справедлива для TypeScript и ему подобных. Чёрт, да даже для asm.js. Я знаю, что asm.js впечатляет в теории, но вы сами пытались пройтись по написанному на нём коду? Это мусор, и вам явно не придётся писать такое в ваших обычных каждодневных исходниках.

От переводчика: Это третья статья из цикла о Node.js от команды Mozilla Identity, которая занимается проектом Persona. Эта статья посвящена применяемому в Persona способу хранения данных сессии на клиенте.

Все статьи цикла:

1. "Охотимся за утечками памяти в Node.js"
2. "Нагружаем Node под завязку"
3. "Храним сессии на клиенте, чтобы упростить масштабирование приложения"
4. "Производительность фронтэнда. Часть 1 — конкатенация, компрессия, кэширование"
5. "Пишем сервер, который не падает под нагрузкой"
6. "Производительность фронтэнда. Часть 2 — кешируем динамический контент с помощью etagify"
7. "Приручаем конфигурации веб-приложений с помощью node-convict"
8. "Производительность фронтенда. Часть 3 — оптимизация шрифтов"
9. "Локализация приложений Node.js. Часть 1"
10. "Локализация приложений Node.js. Часть 2: инструментарий и процесс"
11. "Локализация приложений Node.js. Часть 3: локализация в действии"
12. "Awsbox — PaaS-инфраструктура для развёртывания приложений Node.js в облаке Amazon"

---

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

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

Масштабирование сайта с хранением состояния

Если необходимо масштабировать такой сайт, есть три варианта:

1. Реплицировать данные сессии между всеми серверами.
2. Использовать центральное хранилище, к которому будут обращаться все серверы.
3. Закрепить за каждым пользователем определённый сервер.

У всех этих подходов есть недостатки:

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

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

Проблема

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

Решений проблемы несколько:

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

Все эти способы имеют право на жизнь в определенных обстоятельствах, но когда события обнаруживать нужно (отметаем вариант 1), когда фигуры зачастую не являются прямоугольными, имеют повороты, и прочие трансформации (вариант 2 тоже не подходит), когда фигуры не являются геометрически правильными, как например, сглаженые сплайнами линии, многоугольники с вогнутими гранями (вариант 3 тоже забыли), а самое главное, когда этих фигур становится бесчисленное множество, и хранить координаты каждой, перебирая их на каждый MouseMove становится накладным, на помощь приходит другой способ.

Я работаю над визуализацией парапланерных соревнований — пишу плеер просмотра гонки для Airtribune.com. В процессе работы мне попадаются интересные и нестандартные задачи. Одна из них — задача быстрой отрисовки маркеров и треков на карте google maps.

Масштабы такие: есть ~200 трекеров в довольно ограниченной области (50x50км), каждый передает данные о своем положении раз в 10 секунд. Нужно их все отрисовать на карте и плавно перемещать при изменении координат. За каждым маркером должен отрисовываться трек. Картинка примерно следующая:



Скоро обнаружилось, что встроенные объекты — google.maps.Marker и google.maps.Polyline — для данной задачи работают слишком медленно. Была куча идей по оптимизации, и в результате получилось решение на canvas-е, которое работает со скоростью 40fps даже на тысяче маркеров. Впрочем, fps вы можете померить сами — я собрал тестовое приложение для сравнения 4-х движков, в котором на лету можно подключать разные фишки и смотреть на скорость работы.

Многие сталкивались с необходимостью использовать необязательные аргументы функции. Если такой аргумент один, да ещё и последний, то особых проблем не возникает.

function set(name, value){
    if(value == undefined){
        value = name;
    }
    ...
}

Введение

Nashorn^* — движок JavaScript, разрабатываемый полностью на языке программирования Java компанией Oracle. Основан на Da Vinci Machine (JSR 292) и будет доступен в составе Java 8 (релиз которой ожидается в марте 2014 года). Стоит отметить что выполнение JavaScript (и поддержка скриптов в целом) была уже в Java 6, но в ней использовался движок Rhino, также написанный на Java, но поддерживаемый Mozilla Foundation.

О списке нововведений в Java 8 уже писали ранее. В данной статье будет приведена пара простых примеров, которая даст вам представление об использовании Nashorn.

Введение

Так уж сложилось, что у нас в компании ведется учет работ по тестированию в небезызвестных GoogleDocs. Поскольку таким учетом занимаюсь я один, то это идеальный вариант. Плюс еще есть возможность без труда поделиться наработками с коллегами и не нужно заботиться об актуальности версий — все сохраняется моментально.
Это основные причины выбранного варианта работы. Но, как известно, у любой монеты две стороны. Минус такого подхода состоит в том, что большие проекты трудно обрабатывать и составлять вменяемые отчеты по тестированию (для этих целей, безусловно, подходят системы управления тестами).
Совсем недавно я столкнулся с Google Script. Это инструмент, позволяющий намного эффективнее работать с документами в облаке. Я решил, что он подойдет для задачи автоматизированного составления отчетов по тестированию. И вот что получилось.

Структура

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



Очевидно, что такие сценарии не удобно вести на одной странице — есть смысл разбить на несколько листов (например, по этапам или релизам).

Задача

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

Решение

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



Вот что получилось для статистики:

Интенсивное развитие облачных сервисов не оставляет равнодушным. Нашe внимание остановилось на сервисе Amazon — Elasctic Cloud Compute. Возникла задача развернуть проект node.js использующий Derby. Amazon Elastic Beanstalk так же поддерживает node.js, однако мы ограничимся только сервисом Amazon EC2. Кроме того «из коробки» Amazon Elastic Beanstalk предлагают Amazon Linux с предуставновленным node.js + nginx. В нашем случае Amazon Linux не подходит, версия node.js и связка node.js+nginx также.

Chain.js — маленькая библиотека, сделанная для создания цепочек из синхронных и асинхронных функций. Идея цепочек родилась после знакомства с Common JS Promises. Само определение «обещаний» говорит, что promise — это значение выполнения одной операции. Если вам захотелось что-то изобрести, придумать или создать, то вы просто обязаны попытаться связать эти операции в цепочки. Конечно, вы не обязаны, и это естественно, но для меня это стало основным мотивом. Перед этим я действительно столкнулся с некоторыми неудобствами связывания promise-операций, хотя ожидал что именно с этим они мне и помогут.

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

Как я могу судить, для людей, которые на практике не столкнулись с некоторыми специфическими проблемами, эти 2 понятия являются довольно трудными для понимания. И не потому, что понятия Promise и Deferred являются с чем-то сложным, а потому, что довольно непросто сходу выдумать подходящую задачу, чтобы попробовать Deferred objects (в JQuery и не только) в действии.

Да, вероятно для тех, кто знаком с этим вопросом он покажется пустяковым и не стоящим и выеденного яйца. Кроме того, вопрос уже многократно обсуждался. Однако, я наберусь смелости еще раз его затронуть и вот почему: 1) Мне кажется, что для некоторых читателей этот пост может оказаться интересным. 2) Я пойду от практики, а не от теории. Моя задача — продемонстрировать работу инструмента. Теорию и другие варианты применения при необходимости вы найдете в ссылках к посту.

Ниже я попробую показать вам что Promise и Deferred это очень и очень просто. Кроме того, для объяснения этой темы, мне придётся затронуть еще несколько интересных моментов JavaScript.

Привет, Хабр!

Мы выпустили WebStorm 7 — новую версию нашей JavaScript IDE, и с радостью хотим рассказать вам о том, что же нового в ней появилось.

Конечно же, в новом WebStorm 7 вы сможете порадоваться поддержке новых и востребованных технологий, например, JavaScript шаблонов, Stylus, Web Components. К тому же мы значительно переработали и улучшили внутренние инструменты IDE, что должно положительно отразиться на удобстве использования WebStorm и на вашей продуктивности.

Доброго времени суток, уважаемые хабражители. Хочу поделиться с вами одной замечательной находкой на GitHub — SVG.js — удобная манипуляция и анимация SVG. Хочется сказать о трех вещах, которые сосредоточили мое внимание на этой библиотеке. Самое простое и важное это то, что с появлением retina дисплеев SVG становится популярнее, более нужным, чем раньше. SVG.min.js весит 34кб и 9кб в Gzip, что в разы меньше Raphaël и что можно пожертвовать для дизайна и эффектов. Минифицированный SVG.filter.js размером в 3кб является прекрасным кроссбраузерным аналогом для свойства webkit-filter.

На первый поверхностный взгляд, слова JavaScript и «утечка памяти» рядом стоять не могут. Настоящих утечек памяти в JS, конечно, не может быть, потому что процесс сборки мусора происходит автоматически и не может контролироваться из нашего кода. Выделить память под объект и забыть освободить невозможно. Но могут быть ситуации, связанные с ошибками в логике работы приложения, которые приводят к утечкам памяти другого рода. Например, забиндили обработчик, в котором что-то делаем с методами общего объекта и забыли его анбиндить. Или же посылаем письмо с большим телом и не очищаем тело даже после отправки.



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