Эта программа транслирует игры с Raspberry Pi на портативную консоль Game Boy Advance через его соединительный порт. Видео и аудио в режиме реального времени сжимаются и отправляются на консоль, с которой осуществляется управление, что позволяет запускать на геймбое игры с любой платформы (отсюда и название Remote Play — дистанционный запуск)

Сотрудники Node.js и члены Node.js Foundation с гордостью представляют 4.0.0 версию продукта. В этот релиз включены бесчисленные часы совместной работы проектов Node.js и io.js, которые были успешно объедены в одну кодовую базу. Проект Node.js управляется командой из 44 человек, 15 из которых формируют Technical Steering Committee (TSC). Кроме того, более 100 участников были добавлены в список людей, способных влиять на развитие ядра, по сравнению с числом участников версии v0.12.7.

Node.js v4.0.0 содержит V8 v4.5, это та же версия V8, которая поставляется вместе с веб браузером Chrome сегодня. Это привносит с собой множество бонусов для пользователей Node.js, наиболее важные из которых, это поддержка ES6 стандарта, который включен по умолчанию, включая блочную область видимости, классы, типизированные массивы (Node's Buffer теперь работает поверх Uint8Array), генераторы, Promises, Symbols, строковые шаблоны, коллекции (Map, Set, и так далее) и, новая возможность для V8 v4.5 — стрелочные функции.

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

Хочу опубликовать коротенькую заметку о том как интегрировать, зарелизиный совсем недавно, ActionCable в ваш Ruby on Rails проект на примере Live — чата. Я не стану углубляться в то, как работает сам ActionCable, просто приведу небольшой пример использования.

Имею огромное желание рассказать о том, как просто работать с QIWI Shop, используя Ruby on Rails.

Для чего нужен QIWI Shop? Например, у Вас есть свой онлайн-магазин и Вам необходимо принимать платежи от пользователей. Qiwi достаточно распространен в мире. Он не требует наличия персонального аттеста для вывода средств, как это, например, требуют в WebMoney. Поэтому QIWI достаточно привлекателен для интеграрации в онлайн-магазины.

В этой небольшой статье я бы хотел показать настройку Rails — приложения работающего на Nginx'е с Puma и как это все деплоить с помощью Mina.

Предыстория

На создание этой статьи меня толкнула недавняя публикация о деплое. В приведённой статье описан способ разворачивания проекта на основе rbenv, я же опишу ситуацию с rvm и настройкой upstart.

Задачи и требования

Итак, дано: простейшее RubyOnRails-приложение. В случае разворачивания своего проекта я ставил перед собой следующие задачи:

• ОС Ubuntu LTS 14.04;
• Веб-сервер Nginx;
• Сервер приложения Puma;
• Использование RVM для установки ruby требуемой версии;
• Автоматический запуск приложения при запуске VPS-сервера, возможность управлять приложением как службой;
• Автоматизация процесса деплоя с помощью mina;

Почему Ubuntu?
Просто я к ней привык (точнее к её производной — Linux Mint).

Почему puma, а не unicorn или passenger?
О пуме я слышал неплохие отзывы, а у unicron страшненький сайт. Passenger, на мой взгляд, нарушает принцип единственной обязанности — я хочу иметь веб-сервер и приложение-сервер.

Почему RVM?
Я к нему привык — у меня он установлен на локальной машине, хочу его видеть и на production.

Почему mina?
Она действительно проще чем capistrano и при этом быстрее. Скорость достигается за счёт того, что для каждой задачи capistrano создаёт отдельное ssh-соединение. Mina же формирует shell-скрипт и выполняет его в рамках одного соединения.

В данном случае задача легко разбивается на 3 этапа:

1. Убедиться, что приложение корректно запускается (пока без автоматизации);
2. Настроить сервер так, чтобы наше rails-приложение работало как полноценная служба;
3. На основе этого настроить автоматизированное разворачивание с помощью mina.

Думаю многим знакомо понятие «борьба за staging», когда все разработчики одновременно за день до релиза хотят поделиться своими наработками, чтобы тестировщик их проверил как можно скорее и не пришлось всю ночь править баги, да? Кому интересно посмотреть как мы решаем данную проблему для RoR-проектов с помощью Capistrano прошу под кат.

Capistrano — любимый многими rails-разработчиками инструмент, с помощью которого можно быстро и без заморочек автоматизировать развертывание вашего приложения. Capistrano — стандарт де-факто для системы развертывания RoR, must-know технология для любого уважающего себя рубиста, тот инструмент, которому в своё время завидовали разработчики на python и PHP.
Несмотря на комфорт, от которого не хочется отказываться, чем более сложные задачи мне приходилось решать, тем чаще Capistrano показывал себя к ним не приспособленным.

Я отметил следующие недостатки:

• Известные проблемы со скоростью. Вследствие своей универсальности, Capistrano деплоит медленно, выполняя лишние проверки и вызовы, которые вы не всегда можете контролировать.
• Последовательный деплой. Небыстрое время развертывания нужно умножить на количество целевых серверов (однако, можно настроить распараллеливание комманд явным образом).
• Сильная связанность с рельсами. Конфиги и зависимости Capistrano переплетаются с приложением, становясь его частью. Нельзя создать новое окружение-развертывания (например сервера для раннего выкатывания функционала) без создания нового rails-окружения. В сложных ситуациях Capistrano заставляет уходить от хорошей практики держать только development, test и production окружения.
• Плагины — палка о двух концах. Давая возможность быстро “прикрутить” развертывание той или иной зависимости приложения, плагины лишают вас контроля ситуации, заставляют действовать так, как действует разработчик плагина. О влиянии лишних “телодвижений” плагинов на скорость деплоя я написал выше.
• Сложный деплой гетерогенных приложений. Трендом последних лет в рельсах стало выделение самых тяжелых (бекграундных или сетевых) задач в отдельные сервисы, не обязательно написанные на ruby. В такой ситуации capistrano заставляет вас плодить зоопарк из разных систем развертывания для разных языков и технологий.

Многие ruby-разработчики перешли на Mina или решают свои проблемы с помощью ещё более сложных систем управления конфигурациями вроде Chef и Puppet. Все они имеют свои особенности и недостатки и в разной степени решают описанные выше проблемы. Мне же удалось их решить их с помощью Ansible, не растеряв преимуществ Capistrano, к которым я привык.

Ansible это инструмент для управления конфигурациями и в его задачи входит не только описанное в этой статье выполнение удаленных команд на серверах для развертывания и управления отдельным приложением, но и автоматизация серверного администрирования посредством хранимых серверных конфигураций (ролей на языке Ansible). А значит Ansible (как впрочем и Chef и Puppet) позволяет гораздо больше, чем Capistrano и в конечном счете они все не идут с ним ни в какое сравнение. Однако, задача этой статьи дать rails-разработчикам отправную точку для миграции и разъяснить на этом примере основы Ansible. В конце этой статьи, волшебная команда cap production deploy превратится в ansible-playbook deploy.yml -i inventory/production
Кому интересно как — прошу под кат.

Всем привет! Меня зовут Андрей Новиков и в последнее время я работаю над проектом по разработке приложения, которое используется в разных частях нашей страны и автоматизирует работу людей. В каждом конкретном часовом поясе нашему приложению необходимо правильно получать, сохранять и отображать время, причём как в прошлом, так и в будущем – например, рассчитать начало рабочей смены и так же правильно его отображать: отсчитать время до конца смены, показать, сколько люди ехали до точки назначения и определить, уложились ли они в норматив, в также многое-многое другое.



За те уже несколько лет, что я пишу на Ruby on Rails, мне не приходилось сталкиваться с подобными проблемами — до этого все мои приложения работали в одном часовом поясе. А тут неожиданно пришлось немало попотеть, отлавливая самые разные ошибки и пытаясь выяснить, как же работать с датой и временем так, чтобы их в дальнейшем избежать.

В результате, сегодня мне есть, чем с вами поделиться. Если вы регулярно встречаетесь с тем, что время сохраняется или отображается некорректно с характерным разбросом в несколько часов (3 часа для Москвы), какие-то ночные записи перекочёвывают на соседние дни, а время упорно отображается не так, как хотят пользователи, и вы не знаете, что со всем этим делать — добро пожаловать под кат.

Здравствуйте, уважаемые читатели!

Жизнь не стоит на месте, и вот в «O'Reilly» задумались об издании первой фундаментальной книги о языке программирования Rust:



Заинтересовавшись этой темой, мы решили вынести на обсуждение перевод обзорной статьи о языке Rust, вышедшей в декабре 2014 года. Статья немного сокращена с учетом того, что некоторые ее отрывки уже устарели, однако автор хорошо рассматривает этот язык в контексте существующих альтернатив, подчеркивает его (безусловные) достоинства и (условные) недостатки.

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

В начале 2014 года к нам в отдел контентных проектов пришла задача унификации дизайна. Дизайнеры хотели единый стиль проектов и принципы работы интерфейсов. Это будет удобно пользователям, облегчит запуск новых проектов и редизайн существующих (более подробно об этом писал Юра Ветров). Команда фронтенда получит возможность использовать схожие компоненты верстки на разных проектах, что уменьшит время разработки и поддержки существующего функционала. Для команды бэкенда задача оказалась нетривиальной: большинство наших проектов написана на Perl (Template Toolkit), Недвижимость на PHP, Дети и Здоровье используют Django. Но от нас требовалось реализовать не только поддержку единого шаблонизатора, но и согласовать единый формат отдаваемых данных в шаблоны. Обилие подгружаемых AJAX-блочков требовало поддержку еще и клиентской шаблонизации.

Таким образом, задача унификации дизайна превратилась в задачу выбора единого шаблонизатора для Perl, Python, PHP и JS.

Прогрессбар — элемент вроде и редко встречающийся на сайтах (в отличии от селектов, чекбоксов, инпутов и прочего), но все равно без него не обойдется ни один ui-kit.

На данный момент HTML5 предоставляет нам нативный элемент progress, базовый функционал которого поддерживается практически всеми современными браузерами (caniuse.com/#feat=progress).

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

“Ты совсем рехнулся с этим WebGL!”, как-то заявил мне знакомый разработчик: “Изучаешь новый движок ради одной платформы?!”

А ведь и, правда, работая с Unity, я получаю доступ ко многим платформам. Работая с Blend4Web — только к одной. Крупные компании могут позволить себе использовать несколько технологий для качественного портирования игры, в случае инди — это большая проблема.

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

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

Ряд публикаций Джейсона Орендорфа ES6 In Depth посвящен ES6, который добавили в язык программирования JavaScript в 6 итерации ECMAScript.

Сегодня будем делать такие штуки:



Немного сложно для первого примера. Подробнее объясню позже, пока что посмотрим, что за объект мы создали.

Вот уже на протяжении четырёх лет, с сентября 2011 г. W3C занимается разработкой CSS4. Модули четвёртой версии каскадных таблиц стилей проектируются на базе CSS3 и дополняют их новыми свойствами и значениями. В этой статье я хотел бы рассказать о том, как использовать возможности CSS4 уже сегодня, о cssnext.

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

В предыдущей части я рассказал про представления. Теперь поговорим про контроллеры.
В этой части я расскажу про:

• REST
• gem responders
• иерархию контроллеров
• хлебные крошки

Контроллер обеспечивает связь между пользователем и системой:

• получает информацию от пользователя,
• выполняет необходимые действия,
• отправляет результат пользователю.

Контроллер содержит только логику взаимодействия с пользователем:

• выбор view для отображения данных
• вызов процедур обработки данных
• отображение уведомлений
• управление сессиями

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

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

Основная проблема проектов на RoR в том, что, как правило, всю логику пытаются уместить в модели, контроллеры и представления. Т.е. код находится только в моделях(ActiveRecord::Base), контроллерах, хэлперах и шаблонах. Такой подход приводит к печальным последствиям: код становится запутанным, долго делаются фичи, появляются регрессии, у разработчиков пропадает мотивация. В качестве примера можно посмотреть на исходники redmine.

Выход из данной ситуации довольно-таки очевидный. Будем делать проекты не на ruby on rails, а с использованием ruby on rails. Как это будет выглядеть: мы никуда не уходим от MVC и Rails, просто пересмотрим Model, View, Controller. Для начала расширим понятие модели. Модель — это не просто класс-наследник ORM. Модель — это вся бизнес логика приложения. Модель включает в себя: модели, сервисы, политики, репозитории, формы и другие элементы, которые я опишу далее. Так же расширим представления. Представления — это шаблоны, презентеры, хелперы, билдеры форм. Контроллеры — это все то, что связано с обработкой запросов: контроллеры, responders.

Ни для кого не секрет, что сейчас можно легко скачать эмулятор почти любой игровой консоли 80х-90х и поиграть в классические игры на компьютере, телефоне и многих других платформах. В сети легко можно найти и ROM'ы этих самых игр. Зачастую люди качают их и даже не задумываются, каким же образом кто-то однажды прочитал их из картриджа. В этой статье я и постараюсь рассказать, как же это делалось в случае с NES/Famicom, которая у нас была больше известна как «Денди», и покажу, как можно сделать это самостоятельно.

Не так давно Microsoft объявила о выпуске TypeScript 1.6 Beta, одним из интересных, на мой взгляд, нововведением является поддержка React/JSX, что в совокупности с особенностями TypeScript'а открывает новые возможности.



Я расскажу о личном опыте — как начал использовать связку TypeScript + React, с каким проблемами столкнулся и как их решал. А так же покажу примеры gulp-тасков для того, чтобы это все заработало и продемонстрирую код минимального todo приложения на TypeScript + React (ссылка на Github).

Если вам это интересно — пожалуйста, заходите под кат.