...

суббота, 12 июля 2014 г.

Нет времени объяснять, придумайте реально сложный пароль к Скайпу

Потому что он хранится в виде хеша типа MD5(user,"\nskyper\n",pass).

В следующей версии утилиты для взлома хешей с использованием GPGPU oclHashcatпоявится возможность взламывать такие хеши(впрочем это можно делать уже сейчас), скорость перебора таких хешей, а следовательно и ваших паролей, составляет сейчас около 4 GHash/s(млрд.паролей в сек) одной AMD R9 290X.

«Что это значит для меня?», — возможно спросите вы. Это значит, что пароль из 10 цифр возможно подобрать за 2(две) секунды, а полностью случайный пароль длиною в 8 ЛаТИнсКиХ БуКв и цифр всего за 15 часов, одной видеокартой, а ведь есть и специализированные фермы, а также перебор по словарям, что существенно упрощает задачу.

Мне нечего здесь добавить.

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.


Один день * Два Демопати

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

Итак, что–же происходит прямо сейчас? DemoParty: DiHalt и 3ВМ OpenAir



3BM OpenAir

image

Довольно молодой конкурс, проводимый энтузиастами zx–spectrum сцены. Организован известными на zx-сцене художниками и кодерами. Проводится как маленькое пати для своих в Перми, но при этом имеет голосование онлайн с выставкой работ.

Работы — только для zx spectrum.


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

Примечательно, что на этом конкурсе уже представлены демо для современных расширений Спектрума. Моя — Rubicon.

Есть возможность посмотреть и пообщаться в IRC


DiHalt

image

Популярный конкурс, собирающий большую массу народу со всей России. Проводится в Нижнем Новгороде как общероссийский конкурс компьютерного творчества для многих популярных платформ — PC, Amiga/Pegasos, 8–битных платформ, созданных до 1993г. включительно.

На ДиХальт обычно выставляется много музыкантов, художников и кодеров для zx spectrum.

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

интересно будет понаблюдать трансляцию, можно будет просмотреть работы и проголосовать онлайн, а так–же пообщаться с современными фанатами Спектрума в IRC :)


Приглашаю!


This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.


Простое удалённое управление с компьютера роботом

Предисловие или зачем извращаться?



Здравствуй, Хабрахабр! Я сидел вечером 11 июня, смотрел фильм. Неожиданно для себя я обнаружил, что мне написала незнакомая мне ранее женщина с предложением сделать робота для их нового квеста. Суть заключается в том, что нужно разгадывать головоломки, исследовать тайники, правильно применять подсказки, использовать доступные вещи и в итоге добывать ключи и открывать двери… От меня требовалось сделать робота, управляемого с компьютера с помощью отдельной программы. У мебя были сомнения по поводу 2 вещей: успею ли я и как именно сделать беспроводную передачу данных (беспроводной передачей данных я занимался до этого только на NXT)? Взвесив все за и против я согласился. После этого я стал думать над передачей данных. Поскольку требовалось сделать робота быстро, то вспоминать и доосваевать, например, дельфи не было времени, поэтому возникла идея сделать модуль который будет заниматься отправкой команд. От компьютера требуется просто посылать данные в СОМ-порт. Этот способ странный, но наиболее быстрый. Его я и хочу описать здесь. Так же я приложу 3 программы которые помогут сделать радиоуправляемую машинку.
Сборка передатчика и его программа.



Я сделал модуль для компьютера из FTDI Basic Breakout 5/3.3V от DFrobot, довольно распространённого микроконтролера ATMEGA 328P-PU с загрузчиком Arduino и радиомодуля на основе микросхемы nRF24L01. По-сути это просто Arduino Uno с радиомодулем. Что есть, то есть. У радиомодуля есть особенность, которую я не сразу заметил: входное напряжение должно быть в диапазоне от 3 до 3.6 вольт (хотя подача на него 5 вольт его не убьёт, но работать не будет), верхняя граница логической единицы составляет 5В. Это означает то, что для подключения радиомодуля к меге не нужен преобразователь уровней между 3.3В и 5В, а вот стабилизатор на 3.3В установить нужно. У FTDI есть встроенный стабилизатор, от него я и подпитал радиомодуль.

Так выглядит сам модуль (внутри и в сборке) :


Программа состоит из инициализации, стартового сообщения и обработки команд из программы управления. Так было в моём случае. Основные команды библиотеки Mirf:


#include <SPI.h>

#include <Mirf.h>

#include <MirfHardwareSpiDriver.h>

#include <MirfSpiDriver.h>

#include <nRF24L01.h>

Эти библиотеки нужны для работы радиомодуля


Mirf.csnPin = 4 — задаёт номер пина, отвечающего за «разрешение общаться» радиомодуля и МК

Mirf.cePin = 6 — задаёт номер пина, отвечающего за режим работы радиомодуля (приёмник/передатчик)

Mirf.spi = &MirfHardwareSpi — настраивает линию SPI

Mirf.init() — инициализирует радиомодуль

Mirf.payload = 1 — размер в байтах одного сообщения (поумолчанию 16, максимум 32)

Mirf.channel = 19 — задаёт канал (0 — 127, по умолчанию 0)

Mirf.config() — задаёт параметры передачи


Mirf.setTADDR((byte *)«serv1») — переводит радиомодуль в режим передатчика

Mirf.setRADDR((byte *)«serv1») — переводит радиомодуль в режим приёмника


Mirf.send(data) — отправляет массив типа byte

Mirf.dataReady() — сообщает об окончании обработки принятых данных

Mirf.getData(data) — записать принятые данные в массив data


Mirf.setTADDR((byte *)«serv1») — переводит радиомодуль в режим передатчика

Mirf.setRADDR((byte *)«serv1») — переводит радиомодуль в режим приёмника


Mirf.send(data) — отправляет массив типа byte

Mirf.dataReady() — сообщает об окончании обработки принятых данных

Mirf.getData(data) — записать принятые данные в массив data


Прилагаю код программы передатчика.


Программа передатчика
#include

#include

#include

#include

#include

char active;

byte data[1];


void setup()

{

Serial.begin(19200);


Mirf.csnPin = 4;

Mirf.cePin = 6;

Mirf.spi = &MirfHardwareSpi;

Mirf.init();

Mirf.payload = 1;

Mirf.channel = 19;

Mirf.config();


Mirf.setTADDR((byte *)«serv1»);


//сигнальное сообщение о начале работы

data[0]=7;

Mirf.send(data);

delay(200);

}


void loop()

{

if (Serial.available()) //Если данные готовы к считыванию

{

active=Serial.read(); // Запись данных в переменную

}


if (active=='2')

{

data[0]=2;

}


if (active=='3')

{

data[0]=3;

}


if (active=='4')

{

data[0]=4;

}


if (active=='5')

{

data[0]=5;

}


if (active=='6')

{

data[0]=6;

}


Mirf.send(data); //Отсылаем данные

while(Mirf.isSending()); // Ждём пока данные отсылаются

}




Программа управления.

Есть одна интересная штука — Processing. Синтаксис такой же как в Arduino, только вместо void loop() там расположился void draw(). Но она становилась ещё более интересной в моей ситуации с библиотекой processing Serial, которая позволяет работать с сериал-портом. Прочитав уроки на сайте Spurkfun`а, я поигрался с миганием светодиода на подключенной к компьютеру ардуинке по клику мышки. После этого я написал программу управления роботом с клавиатуры. Прилагаю код управления с помощью стрелок. В нём, в принципе, ничего необычного нет.


Программа управления машинкой
import processing.serial.*;

import cc.arduino.*;

Serial myPort;

PFont f=createFont(«LetterGothicStd-32.vlw», 24);


void setup()

{

size(360, 160);

stroke(255);

background(0);

textFont(f);


noCursor();


String portName = «XXXX»; // Сюда нужно написать имя вашего порта

myPort = new Serial(this, portName, 19200);

}


void draw() {

if (keyPressed == false)

{

clear();

myPort.write('6');

println(«6»);

}

}


void keyPressed()

{

// 10 — enter

// 32 — probel

// 37/38/39/40 — keys

clear();


fill(255);

textAlign(CENTER);

//text(keyCode, 180, 80);


switch(keyCode)

{

case 37:

text(«Edem vlevo», 180, 80);

myPort.write('1');

break;


case 38:

text(«Edem pryamo», 180, 80);

myPort.write('2');

break;


case 39:

text(«Edem vpravo», 180, 80);

myPort.write('3');

break;


case 40:

text(«Edem nazad», 180, 80);

myPort.write('4');

break;


default:

text(«Takoy kommandi net», 180, 80);

myPort.write('6');

break;

}

}




Программа приёмника.

Инициализация этой программы отличается от инициализации программы передатчика буквально одной строчкой. Ключевая команда в бесконечном цикле Mirf.getData(data). Дальше полученная команда сравнивается с числами, которым соответствуют какие-либо действия робота. Ну а дальше робот действует точно по командам. Прилагаю код программы приёмника машинки.


Программ машинки
#include

#include

#include

#include

#include

void setup()

{

Serial.begin(9600);


pinMode(13, OUTPUT); //LED


Mirf.csnPin = 10;

Mirf.cePin = 9;

Mirf.spi = &MirfHardwareSpi;

Mirf.init();

Mirf.payload = 1;

Mirf.channel = 19;

Mirf.config();

Mirf.setRADDR((byte *)«serv1»);

}


void loop()

{

byte data[1];


if(!Mirf.isSending() && Mirf.dataReady())

{

Mirf.getData(data);

Serial.println(data[0]);

}


switch (data[0])

{

case 1:

motors(-100, 100); // поворачиваем влево

break;


case 2:

motors(100, 100); // едем прямо

break;


case 3:

motors(100, -100); // поворачиваем вправо

break;


case 4:

motors(-100, -100); // едем назад

break;


default:

motors(0, 0); // стоим

break;

}


delay(50);

}




Заключение.

Что из этого всего вышло:

http://ift.tt/1y8dFoK


Этого робота я сделал для «Клаустрофобии». Они проводят квесты в реальности в разных городах, и как раз для одного из таких квестов организаторам понадобился радиоуправляемый робот-сапер. Мне понравилось. Это, конечно, ущербно, т.к. на фоне управления с помощью встроенных в ноутбук средств связи, но зато своё, сделанное весьма быстро и без особых проблем. Надеюсь эта статья поможет сделать нечто подобное, а, может, даже сложнее. Тут уж кому что захочется.


This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.


[Из песочницы] ZExt PHP Framework

Данным постом хочу представить IT-сообществу свой давний проект: PHP фреймворк «ZExt».

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



Фреймворк представляеться «как есть» и его автор не несёт ответственности за его использование.

Репозиторий на GitHub.


Фреймворк требует PHP версии не ниже 5.4.

Для работы компонентов требуется добавить пространство имён «ZExt» в автозагрузку классов (PSR-0) по пути: «my_app_library/ZExt».


Можно воспользоватся собственным автозагрузчиком классов фреймворка:



require 'my_app_library/ZExt/Loader/Autoloader.php';

ZExt\Loader\Autoloader::registerDefaults();


Так же можно добавить фреймворк через Composer:



{
"require": {
"zext/zext": "dev-master"
},
"repositories": [
{
"type": "git",
"url": "http://ift.tt/1y8aHk0"
}
]
}


Теперь немного о его компонентах:


Debug




Компонент представляющий набор средств для отладки PHP-приложений.

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

Использует jQuery подключенный в вашем проекте или, при его отсутствии, подключает сам через GoogleApis.

Подключение отладочной панели с параметрами по умолчанию:



$debug = ZExt\Debug\DebugBar::initDefaults();




Вывод информации производится в нужном месте (на пример в скрипте вида (view)) через приведение объекта отладчика к строке:

echo $debug;




Результатом работы отладчика будет вот такая панель:


Попробуем бросить исключение:



throw new Exception('Looks like an error occurred...', 100);




При этом отладчик, перехватив его, вернёт отладочную информацию в качестве ответа на запрос:



Слева появился элемент «Exception» с информацией о брошенном исключении.

Совершим не фатальные ошибки:



echo $undefinedVar;

trigger_error('something wrong');





Profiler




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

Сымитируем обращение к некому сервису приложения и добавим профилировщик в панель отладки:



$profiler = new ZExt\Profiler\Profiler();

$profiler->startRead('Database read');
sleep(1); // Read from some service
$profiler->stopSuccess();

$profiler->startWrite('Database write');
sleep(1); // Write to some service
$profiler->stopError();

$profiler->setName('Database')
->setIcon('db');

$debug->addProfiler($profiler);




Теперь посмотрим результаты:


Html




Компонент призван облегчить создание различных HTML-конструкций.

Возмём тег с большим количеством атрибутов:



$tag = new ZExt\Html\Tag('iframe');

$tag->width = 640;
$tag->height = 480;
$tag->frameborder = 0;
$tag->scrolling = 'no';
$tag->src = 'page.php';
$tag->id = 'frame';

echo $tag;



<iframe width="640" height="480" frameborder="0" scrolling="no" src="page.php" id="frame"></iframe>




Список:

$list = new ZExt\Html\ListUnordered();

$list->id = 'list';
$list->title = 'My list';

$list[] = 'Item 1';
$list[] = 'Item 2';
$list[] = 'Item 3';
$list[] = 'Item 4';

echo $list;



<ul id="list" title="My list">
<li>Item 1</li>
<li>Item 2</li>
<li>Item 3</li>
<li>Item 4</li>
</ul>


Планы развития




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

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

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


This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.


Графические модели в машинном обучении. Семинар в Яндексе

Несмотря на огромную популярность аппарата графических моделей для решения задачи структурной классификации, задача настройки их параметров по обучающей выборке долгое время оставалась открытой. В своем докладе Дмитрий Ветров, рассказал об обобщении метода опорных векторов и некоторых особенностях его применения для настройки параметров графических моделей. Дмитрий – руководитель группы Байесовских методов, доцент ВМК МГУ и преподаватель в ШАДе.

Видеозапись доклада.


План доклада:



  • Байесовские методы в машинном обучении.

  • Задачи с взаимозависимыми скрытыми переменными.

  • Вероятностные графические модели

  • Метод опорных векторов и его обобщение для настройки параметров графических моделей.


Сама концепция машинного обучения довольно несложная – это, если говорить образно, поиск взаимосвязей в данных. Данные представляются в классической постановке набором объектов, взятых из одной и той же генеральной совокупности, у каждого объекта есть наблюдаемые переменные, есть скрытые переменные. Наблюдаемые переменные (дальше будем их обозначать X) часто называются признаками, соответственно, скрытые переменные (T) — это те, которые подлежат определению. Для того, чтобы эту взаимосвязь между наблюдаемыми и скрытыми переменными установить, предполагается, что у нас есть обучающая выборка, т.е. набор объектов, для которых известны и наблюдаемые и скрытые компоненты. Глядя на нее, мы пытаемся настроить некоторые решающие правила, которые нам позволят в дальнейшем, когда мы видим набор признаков, оценить скрытые компоненты. Процедура обучения приблизительно выглядит следующим образом: фиксируется множество допустимых решающих правил, которые как правило задаются с помощью весов (W), а дальше каким-то образом в ходе обучения эти веса настраиваются. Тут же с неизбежностью возникает проблема переобучения, если у нас слишком богатое семейство допустимых решающих правил, то в процессе обучения мы легко можем выйти на случай, когда для обучающей выборки мы прекрасно прогнозируем ее скрытую компоненту, а вот для новых объектов прогноз оказывается плохой. Исследователями в области машинного обучения было потрачено немало лет и усилий для того, чтобы эту проблему снять с повестки дня. В настоящее время, кажется, что худо-бедно это удалось.



Байесовская парадигма является подразделом машинного обучения, и в этом случае предполагается, что взаимосвязь между настраиваемыми параметрами W, наблюдаемыми переменными X и скрытыми переменными Т моделируется в виде некоторого совместного распределения, например, на все эти три группы переменных. Соответственно в классической постановке задач машинного обучения т.е., когда предполагается, что данные представляют из себя совокупность объектов, взятых из одной и той же генеральной совокупности независимых объектов, это совместное распределение можно представить вот в таком вот сравнительно простом виде:



Первый множитель отвечает за распределение скрытой переменной при известных признаках и заданном решающем правиле. Второй множитель отвечает за распределение наблюдаемых переменных при заданном решающем правиле (так называемых дискриминативных моделях). Этот множитель нас не интересует, поскольку мы не моделируем распределение наблюдаемых переменных. Но более в общем случае так называемых генеративных моделей он имеет место быть. И, наконец, последний множитель, который неизбежно вытекает, если мы просто рассмотрим правило работы с вероятностями – это априорное распределение на веса W, т.е. на значения параметров решающего правила. И вот именно тот факт, что у нас появилась возможность задавать это априорное распределение, наверное, и явился ключевой причиной, почему Байесовские методы последние 10 лет переживает бум. Долгое время, до середины девяностых годов, Байесовский подход к теории вероятностей достаточно скептически воспринимался исследователями по той причине, что он предполагает, что мы каким-то образом должны задавать априорное распределение на параметры. И традиционный вопрос был – откуда его брать. Функция правдоподобия, понятно, определяется данными, а априорное распределение брать с потолка? Ясно что, если будем брать по-разному априорное распределение, будем получать в итоге разные результаты, применяя формулу Байеса. Поэтому долгое время Байесовский подход казался некоторой игрой ума. Тем не менее, примерно в середине девяностых годов пошел шквал работ, где доказывалось, что общие, стандартные методы машинного обучения можно существенно улучшить, если мы будем учитывать специфику решаемой задачи.


Оказалось, что специфика много где есть, вроде как все задачи сводятся к стандартным постановкам, но в большинстве случаев есть некоторая специфика, некоторые априорные предпочтения на ту или иную форму решающего правила. Т.е. фактически предпочтения на те или иные значения весов W. И тогда возник вопрос, как это можно объединить с качеством работы решающего правила на обучающей выборке? Традиционно процедура машинного обучения выглядит как минимизация ошибки на обучении, т.е. мы пытаемся построить решающее правило так, чтобы как можно точнее прогнозировать переменные Т для обучающей выборки, для которой они известны. Т.е. мы можем оценить качество. Это один показатель. Другой показатель заключается в том, что мы считаем, некоторые значения W более предпочтительными.


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


Эти методы уже неплохо разработаны. Не будет сильным преувеличением сказать, что классическая постановка задачи машинного обучения решена. И как это часто бывает в жизни, как только мы закрыли классическую постановку, тут же оказалось, что нас больше интересуют неклассические постановки, которые оказались гораздо более богаты и интересны. Неклассическая постановка в даном случае — это ситуация, когда скрытые переменные объектов оказываются взаимозависимы. Т.е. мы не можем определить скрытую переменную каждого объекта, глядя только на признаки этого объекта, как предполагалось в традиционной задаче машинного обучения. Более того, она зависит не только и не столько от признаков других объектов, сколько от скрытых переменных других объектов. Соответственно, мы не можем определять скрытую переменную каждого объекта независимо, только в совокупности. Ниже я приведу большое количество примеров задач с взаимосвязанными скрытыми компонентами. Можно заметить, что эти взаимосвязи, т.е. осознание того факта, что скрытые переменные в нашей выборке взаимозависимы, открывает широчайшие возможности для дополнительной регуляризации задач. Т.е. в конечном итоге для дальнейшего поднятия точности решения.


Сегментация изображений





Первый наиболее классический пример — сегментация изображений. Это средство, которое решать такие задачи с взаимозависимыми скрытыми переменными, с него, собственно и начался бум графических моделей. Задача стала крайне востребована с развитием цифровых камер. Что это такое? Для каждого пикселя мы пытаемся поставить некоторую метку класса. В простейшем случае с бинарной сегментацией мы пытаемся отделись объект от фона. В более сложных случаях мы пытаемся для объектов еще и какую-то семантику привнести. В принципе, эту задачу можно рассматривать как стандартную задачу классификации. Каждый пиксель является объектом, каждый пиксель может принадлежать к одному из К классов, у каждого пикселя есть определенный набор признаков. В простейшем случае это цвет, можно снять текстурные признаки, какую-то контекстную информацию, но представляется достаточно очевидным, что в данном случае у нас есть некоторая специфика. Соседние пиксели скорее всего принадлежат к одному и тому же классу, просто потому что в задаче сегментации мы предполагаем, что у нас результатом сегментации будут некоторые компактные области. Как только мы попытаемся этот факт формализовать, у нас неизбежно вытекает, что мы не можем каждый пиксель классифицировать или сегментировать в отрыве от всего остального, мы можем сегментировать только всю картинку сразу. Вот простейшая задача, в которой появились взаимозависимости между скрытыми переменными.


Видеотрекинг





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


Анализ социальных сетей





Анализ социальных сетей сейчас – вполне очевидная задача. Каждого пользователя социальных сетей, конечно, можно анализировать независимо от других, но очевидно, что мы при этом потеряем значительный пласт информации. Например, мы пытаемся анализировать пользователей на предмет их оппозиционности действующему режиму. Если у меня стоит баннер «Навального в президенты!» или «Навального в мэры!», меня, конечно, можно идентифицировать как оппозиционера, но если я более осторожно к этому подхожу и подобные баннеры не вывешиваю, то определить, что я симпатизирую оппозиции, можно только проанализировав моих друзей менее осторожных, которые эти баннеры радостно развешивают. Если окажется, что я с большим количеством таких людей нахожусь в статусе друзей, то вероятность того, что я сам тоже симпатизирую этим течениям, несколько повышается. Ну а если уйти от подобной гбшной тематики, то, допустим, ту же задачу адресной рекламы можно решить гораздо лучше, если мы будем задействовать не только данные про конкретного пользователя (скажем, анкетные данные, которые он сообщил у себя на страничке), но и глядя на круг его друзей.


Вписывание 2D и 3D моделей





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


Декодирование зашумленных сообщений





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


Была выведена теоритическая формула. Больше информации, чем предсказывает теорема Шеннона, передать по зашумленному каналу нельзя в принципе. Но оказывается, что по мере приближения к этому теоритическому пределу, т.е. чем более эффективно мы пытаемся информацию передавать, применяя некоторые хитрые схемы архивации и добавление контрольных битов, которые как раз направлены на исправление ошибок, тем сложнее у нас схема декодирования этого сообщения. Т.е. наиболее эффективные помехоустойчивые коды крайне сложны в декодировке. Там не существует простых формул декодирования. Соответственно, если мы достигаем предела Шеннона, сложность декодирования возрастает экспоненциально. Закодировать и передать сообщение мы можем, а расшифровать его уже не в состоянии. Оказалось, что современные коды, разработанные и стандартизованные в нулевые годы (их сейчас используют в в большинстве мобильных устройств), близки к этому теоретически возможному пределу, и для их декодировки используются так называемый алгоритм передачи сообщений, основанный на алгоритме распространения доверия, который появился в теории графических моделей, возникшей в попытке решить задачу с взаимосвязанными скрытыми переменными.


Имитационное моделирование





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


Сначала это получили в теории, потом убедились, что на практике действительно такое бывает. Действительно для каждой трассы, в зависимости от ее развязок, существует некая предельная пропускная способность, при которой поток еще движется стабильно. Этот эффект скачкообразного перехода от стабильного движения к мертвой пробке — один из примеров фазовых переходов. Оказалось, что в агентских системах такие явления встречаются сплошь и рядом, и условия, при которых происходит фазовый переход, отнюдь не тривиальны. Для того, чтобы можно было моделировать, необходимы соответствующие средства. Если уж я говорю, что это мультиагентские системы, значит агенты – объекты, а объекты между собой взаимодействуют. У нас взаимозависимости между переменными, описывающими каждого агента.


Глубинное обучение





Следующий пример – глубинное обучение. Картинка взята из доклада представителя корпорации Google на конференции ICML 2012, где они произвели фурор тем, что смогли существенно поднять качество классификаций фотографий из базы Flickr путем применения сравнительно молодой парадигмы в машинном обучении — deep learning. В каком-то виде это реинкарнация нейронных сетей на новый лад. Традиционные нейронные сети успешно приказали долго жить. Тем не менее, они инспирировали в каком-то виде появление иного подхода. Глубинные сети, сети Больцмана, которые из себя представляют некую совокупность ограниченных машин Больцмана. По сути это слои взаимосвязанных между собой бинарных переменных. Эти переменные можно интерпретировать как скрытые переменные, которые при принятии решения каким-то образом настраиваются по наблюдаемым переменным. Но особенностью является то, что все скрытые переменные здесь между собой хитрым образом взаимозависимы. Чтобы такую сеть обучить и для того, чтобы в рамках такой сети принять решение, нам опять приходится применять методы, основанные на анализе объектов с взаимозависимыми переменными.


Коллаборативная фильтрация





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


Графические модели




Надеюсь, что мне удалось показать актуальность того, что действительно от классических постановок машинного обучения приходится отходить, и что мир на самом деле сложнее и интереснее. Приходится переходить к задачам, когда у нас есть объекты, у которых есть взаимозависимые скрытые компоненты. Как следствие, приходится моделировать сильно многомерное распределение, например, на скрытые компоненты. Тут возникает неприятность. Представим простейшую ситуацию. Скажем, тысяча объектов, у каждого из них скрытая переменная бинарна, может принимать значения 0/1. Если мы хотим задать совместное распределение, где все зависит от всего, значит, нам нужно формально задать тысячемерное распределение на бинарные переменные. Вопрос: сколько нам для этого потребуется параметров, чтобы такое распределение задать? Ответ: 21000 или приблизительно 10300. Для сравнения, количество атомов в наблюдаемой вселенной — 1080. Очевидно, что задать 10300 мы не можем, даже если объединим вычислительные мощности всего мира. Представим картинку 30x30, у которой каждый пиксель может принимать значение объект/фон. Распределение на множестве таких картинок мы не можем посчитать в принципе, так как распределение дискретно и требует 21000 параметров.

Что же делать? Первый вариант который приходит в голову, предположим, что каждый пиксель у нас распределен независимо от других. Тогда нам потребуется всего тысяча параметров, т.е. вероятность того, что каждый пиксель принимает значение, скажем, 1. Тогда -1 — это вероятность того, что он принял значение 0. Так работает стандартное машинное обучение. Одна маленькая проблема — все переменные стали независимы. Значит, ни одну из перечисленных задач мы таким образом решить не можем. Вопрос: как нам ограничится небольшим количеством параметров, но задать распределение, в котором все зависит от всего? И вот тут как раз на помощь приходит парадигма графических моделей, которая предполагает, что у нас совместное распределение может быть представлено в виде произведения некоторого количества факторов, определенных на пересекающихся подмножествах переменных. Для того, чтобы эти факторы задать, традиционно использовался неориентированный граф, который связывает какие-то объекты в выборке между собой, и система факторизации определяется максимальными кликами этого графа.



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


Основные задачи




Какие же в рамках теории графических моделей возникают основные задачи? Аппарат был такой предложен в конце девяностых годов: совместное распределение моделировать в виде некоторой системы факторизации. Предположим, мы такую систему ввели. Тогда возвращаемся к задачам машинного обучения, которые в Байесовской формулировке предполагали, что у нас задано распределение на три группы величин: скрытые переменные Т, наблюдаемые переменные X и параметр решающего правила W. Оказалось, что в рамках графических моделей задачи очень похожи.


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


  2. Определение нормировочной константы Z . Вычислять ее не всегда легко.

  3. Обучение с учителем. Дана обучающая выборка, в которой мы знаем не только наблюдаемые переменные, но и скрытые. Это некоторая совокупность взаимосвязанных объектов. Требуется найти вектор W, который обращает в максимум совместное распределение.


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


  5. Маргинальные распределения. Дана выборка, известны наблюдаемые компоненты Х, известно решающее правило W, но мы хотим найти не наиболее вероятную конфигурацию всех скрытых переменных выборки, а распределение на скрытые переменные для какого-то одного объекта. Задача часто актуальна в приложениях. Решается нетривиально.



Оставшаяся часть доклада посвящена разбору задачи обучения с учителем. Посмотреть доклад целиком можно здесь.


This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.


[Перевод] Metal, новый графический API для iOS 8

Наступают чудесные времена для графики на iOS 8!



imageНа недавней WWDC компанией Apple был представлен новый графический API под названием Metal, отличительной особенностью которого стала высокая эффективность, низкий уровень издержек и оптимизация под чип A7. Это предоставляет разработчикам возможность воспользоваться всеми аппаратными преимуществами устройств на iOS и добиться намного большего уровня реалистичности, детализации и интерактивности в играх, чем когда бы то ни было.

В данный момент процесс реализации поддержки Metal уже запущен, а пока мы бы хотели рассказать вам кое-что об этой технологии и объяснить, почему же это так круто.



Глянцевый Метал



В Metal заложено несколько ключевых моментов, позволяющих снизить загрузку CPU, просчитать его производительность в определенных условиях и оптимизировать все процессы:

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

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

• У всех устройств на базе iOS единая память для CPU и GPU. Нет необходимости представлять, что данные из CPU должны быть ‘‘скопированы’’ в некую видеопамять. Когда вы создаете буфер обмена, то надо всего лишь указать, что в нем находятся данные, и это ровно та же память, которую будет использовать и GPU.

• Дайте юзеру (движку) осуществлять синхронизацию. OpenGL ES прыгал через множество костылей и о многих моментах ‘’догадывался’’, для того, чтобы можно было реализовывать все возможные сценарии. В Metal синхронизация данных между CPU и GPU является прерогативой юзера. Движок ведь и на самом деле лучше знает, что ему надо делать!

• Все GPU в iOS-устройствах используют архитектуру отложенного рендеринга на основе тайлов. Это в ясном виде используется в Metal API, особенно когда речь идет о целях рендеринга. API теперь не пытается ничего предугадать — все действия с буфером кадров, типа загрузок и сохранений тайлов, и реализации сглаживания, происходят в явном виде.

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

• Новый язык на базе C/C++11 предназначен как для графических, так и для вычислительных шейдеров. А это значит, что iOS будет уметь работать с вычислительными шейдерами, атомарностью, произвольной записью в буфер и прочими фишками с прикольными названиями, которые сейчас доступны на GPU.

• Никакой дурной наследственности, новый API очень прост и отлично оптимизирован. А, и еще у него есть супер-полезный опциональный ‘‘слой отладки’’, который дополнительно все проверяет и уведомляет о любой ошибке или заблуждении, которые вы сделали.

А теперь давайте углубимся в детали еще поглубже!


Вопрос заявок на отрисовку



Если вы занимаетесь созданием игр, особенно для мобильных устройств, то наверняка знаете, что большое количество заявок на отрисовку сильно нагружает процессор. Каждый и любой объект рендеринга требует для себя некоторое количество процессорной мощности, и в реальности на мобильных устройствах вы не сможете единовременно реализовать отрисовку больше нескольких сотен видимых объектов за один раз. В реальности же вы наверняка очень захотите использовать ресурсы CPU и для других нужд — геймплейная логика, физика, AI, анимирование персонажей и все остальное. В Unity есть некие оценочные параметры для минимизации количества сделанных заявок на отрисовку — статический и динамический батчинг (или смешной русскоязычный термин — ‘‘дозирование’’ — прим. перев.), occlusion culling (еще один смешной термин ‘‘окклюзивное обрезание’’ — прим. перев.), LOD (уровни детализации) и distance-based layer culling (удаление слоев в зависимости от их удаленности); кроме того, можно объединять близкие объекты, которые стоят друг рядом с другом, и помещать текстуры в атласы для уменьшения количества материалов.

Хороший вопрос заключается в том, почему должен использоваться ресурс CPU, чтобы что-то отрисовывать? В конце концов, это же то, чем реально должен заниматься GPU.

Некоторые издержки происходят на стороне ‘‘движка’’ — процессору необходимо управлять видимыми объектами, выяснять, какой шейдер сейчас надо рендерить, с каким из объектов какому источнику света необходимо взаимодействовать, какой параметр материала сейчас надо применить и все такое. Что-то из этого закэшировано, что-то выполняется в нескольких потоках; и в целом, это независимый от платформы код. В каждом релизе Unity мы стараемся оптимизировать эту часть, и Metal, в общем, на это никак не влияет.

Однако, в остальной части процессорных издержек можно уличить именно ‘‘графический API и драйвер’’. В зависимости от игры, эта часть может быть очень важной. Metal — это попытка решить вопрос с этой частью, будучи гораздо более подходящей для современного железа, на несколько более низком уровне, и выполняя чудовищно меньшее количество догадок, чем обычно делал OpenGL ES. Упреждающий рендеринг, его создание и валидация; явная загрузка и сохранение рендер-таргетов; отсутствие тацев с бубнами для синхронизации на стороне API — все эти вещи способствуют снижению нагрузки на процессор.

Насколько мы уже успели протестировать, новые API+драйвер загружают CPU всего лишь на несколько процентов. Это существенное снижение, особенно по сравнению с тем, что раньше этот показатель был на уровне 15-40% от полной загрузки CPU! Это значит, что остальное скрывается где-то в нашем коде. И мне кажется, что нам надо продолжать его оптимизацию (смайл).

Ну и не терпится познакомиться с возможностями Metal по объединению рендеринга из нескольких потоков; это также открывает для нас очень интересные возможности для оптимизации.
Возможности вычислений



Благодаря Metal можно будет использовать GPU для вычислений за пределами типовых сценариев: не только для вершинных + фрагментарных шейдеров — но и для шейдеров, известных под названием “вычислительные”. В принципе, это дает возможность запускать любой тип ‘‘параллельных вычислений’’ на множестве маленьких процессоров внутри GPU. Вычислительные шейдеры так же используют концепт ‘‘локального хранилища’’ — очень быстрой выделенной части памяти-на-GPU, которая может быть использована для обмена данными между параллельными рабочими элементами. Такой участок памяти позволяет использовать GPU для вещей, которые очень не просто было бы реализовать с помощью старых добрых вершинных и фрагментарных шейдеров.

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

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



Когда я смогу этим воспользоваться?

Нам не терпится начать отгрузки, но назвать конкретных дат мы пока не можем. Мы уже сделали многое, но нужно еще работать и работать до того, как все будет готово. Наш текущий план — интегрировать все части Metal, что обеспечит мощный прирост производительности процессора. Надеемся, что это произойдет в Unity 5.0. А немного позже мы хотим добавить поддержку вычислительных шейдеров (этот момент немного сложнее и тредует большего внимания с нашей стороны).

Каковы будут системные требования?

Metal будет работать на iOS 8 и устройстве с процессором не слабее A7 (iPhone 5S, iPad Air, iPad Mini Retina).

Что мне нужно будет сделать, чтобы получить преимущества от оптимизации загрузки CPU с помощью Metal?

В общем, ничего. Как только мы добавим поддержку Metal в Unity, все заработает само. Все ваши существующие проекты, все ваши шейдеры и графические эффекты будут просто работать. Просто наслаждайтесь низким уровнем загрузки процессора!


Но что по поводу шейдеров, ведь в Metal для них используется другой язык?

Мы позаботимся и об этом. Сейчас вы, скорее всего, пишете шейдеры на Cg/HLSL, а мы конвертируем это в GLSL для OpenGL ES за кулисами. Для Metal мы будем конвертировать все это примерно таким же образом.


Еще разок, что же мне можно будет сделать благодаря тому, что загрузка CPU будет оптимизирована, и у меня появятся свободные ресурсы?

Улучшить физику, AI или сделать еще сложнее и комплекснее логику и геймплей. Разместить и отрисовать больше объектов на экране. Или просто наслаждаться экономией аккумулятора устройства. Все зависит от вас!


This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.


Как поставить Microsoft Office на линуксах без wine?

image

Плохо это или хорошо, но большинство рабочих компьютеров в мире работают с программным обеспечением MS Office и соответственно пользуются его проприентарными файловыми форматами. До сих пор если у вас на борту линукс, то у вас было два способа работать с такими файлам, ставить MSO через wine (wincon, playonlinux и пр) или пользоваться LIbreoffice (или аналогами), у обоих способов есть свои плюсы и минусы. Работа через wine устраивает не всех, из-за больших требований к железу, не у всех же intel i7 под капотом и для некоторых сложности самой установки, за то они получают подлинный пакет MSO. У LibreOffice к плюсам можно отнести нативность самого ПО т.е. нет проблем с установкой и обновлениями, а к минусам не полную преемственность файлов.


image

Но теперь появился еще и третий способ, так же имеющий свои плюсы и минусы. Это пакет Microsoft Office Online Apps который довольно хорошо работает в большинстве дистов линукс. В данном случае мы получаем полную совместимость фалов, а к минусам можно отнести необходимостью подключения к сети и прямой канал связи с АНБ возможные проблемы с конфиденциальностью.

Ребята из Linux Web Apps project создали (неофициальный) установщик ярлыков для Ubuntu 14.04, думаю будет работать в большинстве ubuntu-совместимых дистрах.


Вот видео установки ярлыков MSO online apps в Elementary OS


Аналогичный проект создан в Google, как можно догадаться работает только через chromium. На данный момент есть Word, Excel, PowerPoint, OneNote. Также в Chrome-store есть еще один проект Open with Office Web Apps Viewer

image

Аналогичный проект создан в Google, как можно догадаться работает только через chromium. На данный момент есть Word, Excel, PowerPoint, OneNote. Также в Chrome-store есть еще один проект Open with Office Web Apps Viewer


This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.


Поиск гамильтонова цикла в большом графе (задача коммивояжера). Часть 3



В этом небольшом посте я продолжу тему, которую поднимал в своих старых двух постах

Часть 1

Часть 2

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


Так что добро пожаловать под хабракат



Старое решение




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

Идея


Идея достаточно проста — давайте запоминать всех, с кем нам было хорошо. В стиле «любовь на века».

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

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


Результаты


Я добавил эту идею в свой алгоритм. Условия были такие — если на каком-то шаге стоимость лучшего решения больше, чем на 30%, ниже остальных текущих решений, то эту ветку решения мы запоминаем. И потом, если мы видим прирост стоимости по лучшему решению достаточно большим(в моей случае это выглядело так — если на одном шаге добавляется больше 5% от суммарной стоимости лучшего решения), то мы делаем rollback, а именно откатываемся, и смотрим, а не даст ли нам сохраненный вариант решение получше.


Так или иначе, это сработало. На том же графе, на котором проверялись алгоритмы первых двух постов, я получил выигрыш 3.5% от лучшего решения.


А что вы думаете по этому поводу?


This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.


Это я, почтальон Печкин!

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



Я живу в Томске. Как то раз ко мне приехали друзья в гости немного, как говориться, потусить. Чудесная встреча, море эмоций и горячительных напитков привело к тому, что друзья — семейная пара из Новосибирска — уехали позабыв свои вещи. Вещь, правда, оказалась одна — косметичка супруги моего друга, туго набитой дорогой косметикой с двумя кредитными картами. Недостачу в вещах обнаружили уже в дороге. Созвонились. Решено было не возвращаться и я пообещал отправить косметичку по почте. Тем более, что вещь не особо ценная, да и расстояние до Новосибирска 270 км, поэтому посылка должна прибыть достаточно скоро. И пошел я на следующий день на почту. Проклял все. Потерял 50 минут времени, но купил коробку, сделал опись, заплатил деньги, заполнил кучу всяких бумажек плохими авторучками, изругался весь, а главное — отстоял бешеную очередь. Хотел уже плюнуть, но должен был получить еще заказное письмо, поэтому пришлось стоять до последнего. После практически часового мучения, но довольный и злой я вышел с почты и сел в машину. Увидев, что мало бензина, решил заехать на заправку. Подъехав к колонке и увидев впереди стоящую машину, я неожиданно оживился.
Заправка как почта?



Впереди меня стояла машина с номерами Новосибирска. Молодой парень заправил полный бак, и, как я понял поехал домой в свой город. У меня возникла простая мысль. Каждый день и каждый час на заправках заправляются люди из разных городов. Особенно на выездных заправках. А что если я бы отдал этому парню свою посылку и он, бросив ее в багажник, уже через несколько часов довез до адресата. А деньги, которые я заплатил Почте России я бы отдал ему. На бензин. Никаких очередей, все быстро и культурно.
Доводим идею до ума



По приезду домой я погрузился в Интернет. Оказалось, что у четырех крупнейших игроков на рынке топлива (бренды не указываю, всем и так понятно) по всей стране построена развитая сеть автозаправок. Как говориться, от Москвы до самых до окраин. Много современных, с магазинами и всякой прочей ерундой. Представим себе, что человек, который хочет оправить посылку, заходит на заправку и покупает некий почтовый набор. Таких наборов, к примеру, три.

1. Картонный конверт для документов формата А4

2. Коробка, в которой можно отправить, к примеру, пару обуви.

3. Коробка, в которой можно отправить что-то побольше, к примеру девайс 25-40-25 см.


Коробки разборные, место много не занимают, имеют на поверхности поле для мобильного телефона отправителя, получателя и QR-код, а также поля для последних пяти цифр паспорта (или для всего номера). Мобильный телефон в этой схеме является единым кодом для обработки данных. Человек, который хочет быть отправителем или получателем должен иметь с собой паспорт, на основании которого принимается и выдается посылка. Водитель, который хочет стать «почтальоном Печкиным» должен один раз заполнить стандартную форму, указав паспортные данные, копию прав и документы на автомобиль. Он устанавливает у себя приложение под Android или iphone, которое имеет все необходимые геоинформационные сервисы (места заправок по стране), обрабатывает данные и сообщает о перемещении посылки. Суть сервиса заключается в том, что я сдаю посылку на заправке, ее через некоторое время забирает водитель в попутном направлении, который сдает посылку на заправке этого же бренда в другом городе. Получатель посылки принимает смс о том, что посылка доставлена, приезжает на указанную в смс или в пользовательском приложении на телефоне заправку и по предъявлению паспорта и сообщив 4 последние цифры своего телефона — забирает посылку себе. Посылка может быть доставлена несколькими водителями. К примеру, один довозит ее до одного города, другой подхватывает и везет дальше.


Где деньги, Зин...



Рассмотрим пример. Я обязан заплатить за доставку посылки. Стоимость доставки должна быть тарифицирована в зависимости от расстояния. К примеру, расстояние 300 км. Стоимость доставки 200 рублей. Я плачу 200 рублей на заправке оператору и отдаю свою посылку. Заправка за услуги по обработке посылки и ее хранения берет комиссию — 20%. То есть 40 рублей. Водитель, который берется довести посылку до заправки в другом городе получает 160 рублей. Но не деньгами, а скидкой на бензин на сумму 160 рублей в том месте, где он сдаст посылку на заправку с тем же брендом. Таким образом, мы привязываем клиента к бренду, он более лоялен и реально экономит деньги. Человек может взять две, три посылки. Конечно, нужно сделать ограничение. К примеру, 1000 рублей на одного водителя. В любом случае затраты на бензин могут быть сведены практически до нуля. Везу посылки, сдаю на заправке, заправляюсь даром. За все заплатили отправители посылок, да и помимо проданного бензина заправка получила комиссию 20% с почтового тарифа. Красота!
Преимущества подхода и недостатки



Первое и самое явное преимущество — скорость доставки. Она невероятна! В примере с моими друзьями из Новосибирска посылка с косметичкой была доставлена через шесть (!) дней. В этом случае посылка может быть доставлена уже через 5-6 часов. Второе преимущество — экономия денег на бензин. Особенно тем, кто постоянно в разъездах, путешествует и т.д. Еще одно преимущество — отсутствие существенных очередей на заправках. Сдать и получить посылку можно за несколько минут. И, наконец, сервис вполне справился бы с «праздничными» затыками почты перед Новым годом, Рождеством, различными праздниками. Сервис был бы полезен интернет-магазинам, которые существенно ускорили доставку вещей заказчикам. Есть, конечно, недостатки. Потери посылок, недобросовестное обслуживание, кражи. Но это можно решать, к примеру, страховыми сервисами и ограничением на разовый забор посылок и т.п. Будут сложности технические. Базы данных, приложения на мобильных платформах не так просты. Могут быть юридические ограничения. Возможно, потребуется лицензирование. Может что-то еще отразиться в комментариях к этому посту.

Всем хорошего дня!


This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.


ВКонтакте объявляет конкурс на редизайн сайта

image

Вчера в 10 вечера Команда дизайнеров ВКонтакте объявила конкурс на создание редизайна социальной сети. Дизайнерам предлагается переделать профиль пользователя, новостную ленту и диалоги. Авторы лучших работ получат самые мощные модели ноутбуков MacBook Pro, поездку в Сан-Франциско для посещения конференции UX Week 2014, которая пройдёт с 9 по 12 сентября, и возможность присоединиться к команде ВКонтакте для работы над ключевыми продуктами сайта: на веб-страницах и мобильных устройствах.


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


Подробнее читайте на специальной странице.


This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.


[Перевод] Pub/Sub JavaScript объект

Перевод статьи «Pub/Sub JavaScript Object», David Walsh

Есть три техники написания AJAX веб-сайтов: делегация событий, управление историей и коммуникация pub/sub на уровне приложения. Я использую все три техники и я хотел бы поделиться с вами самой простой из них: крошечным pub/sub модулем, который я использую на своем веб-сайте.


Если вы не знаете, что такое pub/sub, то суть в том, что вы публикуете в некую тему(topic), и кто угодно может на нее подписываться. Это похоже на то, как работает радио: радиостанция вещает (публикует) и каждый может слушать (подписываться). Это превосходный подход для модульных веб-приложений; это способ глобальной коммуникации без привязки к какому-то конкретному объекту.



JavaScript




Сам по себе модуль очень миниатюрный, но очень полезный:

var events = (function(){
var topics = {};

return {
subscribe: function(topic, listener) {
// создаем объект topic, если еще не создан
if(!topics[topic]) topics[topic] = { queue: [] };

// добавляем listener в очередь
var index = topics[topic].queue.push(listener) -1;

// предоставляем возможность удаления темы
return {
remove: function() {
delete topics[topic].queue[index];
}
};
},
publish: function(topic, info) {
// если темы не существует или нет подписчиков, не делаем ничего
if(!topics[topic] || !topics[topic].queue.length) return;

// проходим по очереди и вызываем подписки
var items = topics[topic].queue;
items.forEach(function(item) {
item(info || {});
});
}
};
})();




Публикуем в тему:

events.publish('/page/load', {
url: '/some/url/path' // любой аргумент
});




… подписываемся на тему, чтобы получать уведомления о событиях:

var subscription = events.subscribe('/page/load', function(obj) {
// делаем что-нибудь, когда событие происходит
});

// ...теперь мне эта подписка больше не нужна...
subscription.remove();




Я скрупулезно использую pub/sub religiously на своем веб-сайте, и этот объект сделал мне кучу добра. У меня есть тема на загрузку страницы через AJAX и несколько подписок, которые вызываются при этом событии (перерисовка рекламы, комментариев, социальных иконок, и тд.). Проверьте, где в вашем приложении можно использовать pub/sub!

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.


[Из песочницы] Легкая и динамическая бизнес логика на JavaScript при помощи Mozilla Rhino

image

Предыстория




Хотелось бы начать с предыстории. В данный момент я разрабатываю некое веб-приложение на Java, ничего необычного, но в документе от заказчика есть требование: будущие администраторы приложения должны иметь возможность налету подгружать код бизнес логики на сервер. Вроде бы ничего сверхъестественного, нужно будет сделать подгрузку java-классов, думал я, пока на днях мне в голову не пришла идея: “А что, если дать возможность программировать методы бизнес логики на JavaScript?”.

В тот момент идея показалась мне очень хорошей, и я видел целый ряд преимуществ этой идеи перед простой подгрузкой java-классов:

  • Во-первых, JavaScript — это очень простой язык описания логики, писать на нем может любой программист, знакомый с принципами ООП и C-подобным синтаксисом.

  • Во-вторых, т.к. внешнее API сервера спроектировано в стиле REST, js-код отлично ложится в рамки ресурса, без проблем сериализуется в JSON-строку и не требует компиляции и дополнительных манипуляций.

  • В-третьих, исполнение JavaScript-кода интерпретатором — это исполнение кода в рамках песочницы безопасности, что дает нам возможность четко настраивать правила поведения кода бизнес-логики.




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

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


Выбираем интерпретатор JavaScript




За движком, который будет интерпретировать для js далеко ходить не пришлось, первым же кандидатом является Mozilla Rhino — js движок, написанный полностью на Java.

Движок берет свое начало от 1997 года, родившись в стенах Netscape под именем “Javagator”, но позже, при загадочных обстоятельствах, был переименован в Rhino. “Носорог” лицензировался некоторыми крупными компаниями(включая Sun) для своих проектов. Изначально идея была в том, что бы компилировать Java-байт код на основе JavaScript, но этот подход имел некоторые проблемы:

  • Во-первых, сам процесс компиляции и подгрузки классов был тяжеловат,

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




В 1998 году в движок добавлен по умолчанию режим интерпретатора, т.е. JavaScript код исполняется на лету, минуя компиляцию в байт код. Это позволило избежать проблем с тяжелой компиляцией и утечками памяти. Позже в этом году движок открывает исходный код и отдается mozilla.org.

Скачать бинарники и исходный код библиотеки можно на оф.сайте: ссылка на сайт. В примерах будет использоваться rhino1.7 R4.

Rhino можно использовать двумя способами: из командной строки и напрямую, встраивая jar-файл в проект. Нас сейчас интересует именно второй способ — добавляем в проект файл js.jar.

Технология LiveConnect




Одно из основных идей Rhino — возможность программировать Java-сервер при помощи JavaScript-кода, используя технологию LiveConnect. Технология дает возможность обращаться к Java-классам напрямую из js, не прибегая к помощи какого-то стороннего кода.

Вот небольшой пример обращения к классам File и System:

var f = new java.io.File(“test.txt”);
java.lang.System.out.println(f.exists());




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

Использование Rhino




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

Начнем, пожалуй, с основ использования. Rhino имеет 2 основных понятия — это контекст(класс org.mozilla.javascript.Context) и сфера(класс org.mozilla.javascript.Scriptable). Контекст — это инстанс интерпретатора, который привязывается к одному потоку, следовательно, интерпретирует js в едином потоке. Сфера — это так называемый namespace, в котором мы определяем все интересующие нас переменные.

Пример создания контекста и сферы:

// Создаем контекст
Context context = Context.enter();

// Создаем сферу
Scriptable scope = context.initStandardObjects();




После того, как мы создали контекст и сферу, мы должны ограничить интерпретатору доступ к Java-классам. Это делается при помощи метода setClassShutter экземпляра контекста:

// Ограничиваем доступ LiveConnect к Java-классам
context.setClassShutter(new ClassShutter() {

@Override
public boolean visibleToScripts(String fullClassName) {
// Определяет, виден ли класс с именем fullClassName скрипту
return false;
}
});




По умолчанию Rhino использует технологию LiveConnect, которая дает доступ к java-классам прямо из js. Она дает большие возможности доверенному коду, но у нас иной случай — наш сервер будет интерпретировать потенциально небезопасный код.

Будет весьма неприятно, если в интерпретатор попадет js-код такого вида:

java.lang.System.exit(0);




Поэтому, мы попросту “затыкаем” LiveConnect и оставляем доступ лишь к тем классам, которые нам нужны. После того, как мы получили контекст и сферу, нам не остается ничего другого, кроме как интерпретировать js-код:

String script = “var mathStuff = Math.cos(Math.PI)”;

c.evaluateString(scope, script, null, 1, null);




Вот и все, после работы с Rhino, завершаем работу с контекстом и освобождаем ресурсы:

Context.exit();


“Песочница” для бизнес логики




Теперь, когда мы знаем, как начать работать с Rhino, можно переходить к определению внешнего API бизнес логики в виде нескольких константных ссылок на модули верхнего уровня:

  • DatabaseModule, который будет отвечать за связь с базой данных,

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



public class DatabaseModule {

public DatabaseModule(){

}

/* Метод возвращает ФИО студента, принимая его идентификатор в качестве аргумента */
public String getStudent(int id){

return (id > 0) ? "Шевченко Константин Викторович" : null;
}

/* Метод возвращает оценку студента, принимая его ФИО в качестве аргумента */
public int getRating(String student){

return student.equals("Шевченко Константин Викторович") ? 5 : -1;
}

/* Метод указывает новую оценку студента, принимая его ФИО и новую оценку в качестве аргументов */
public void setRating(String student, int newRating){
System.out.println("setRating() student = "+student+", newRating = "+newRating);
// Do something
}
}



public class NotificationModule {

public NotificationModule(){

}

/* Метод оповещает студента сообщением */
public void notifyStudent(String student, String message){
System.out.println("notifyStudent() student = "+student+", message = "+message);
}

/* Метод оповещает куратора */
public void notifyCurator(String message){
System.out.println("notifyCurator() message = "+message);
}
}




Далее определяем константные ссылки на модули в ранее определенной сфере:

// Маппим DatabaseModule в js
DatabaseModule database = new DatabaseModule();
Object wrappedDatabaseModule = Context.javaToJS(database, scope);
ScriptableObject.putConstProperty(scope, "databaseModule", wrappedDatabaseModule);

// Маппим NotificationModule в js
NotificationModule notification = new NotificationModule();
Object wrappedNotificationModule = Context.javaToJS(notification, scope);
ScriptableObject.putConstProperty(scope, "notificationModule", wrappedNotificationModule);


Программирование бизнес логики на JavaScript




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

var student = databaseModule.getStudent(1);
var rating = databaseModule.getRating(student);

var pass = rating >= 40;

if(pass){
notificationModule.notifyCurator("Student "+student+" is admitted to the exam.");
notificationModule.notifyStudent(student, "You admitted to the exam.");
} else {
var dif = 40 - rating;
notificationModule.notifyCurator("Student "+student+" needs "+dif+" points to be admitted to the exam.");
notificationModule.notifyStudent(student, "You need "+dif+" points to be admitted to the exam.");
}




Все, что остается, это настроить интерпретатор и передать ему js. Предупрежу сразу: движок болезненно воспринимает кириллицу.

Заключение




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

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

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

  • Безопасность скрипта: не имеет ли он рекурсий и бесконечных циклов, не сильно нагружает ли он память,

  • Валидация скрипта: правильно ли он написан, правильно ли он взаимодействует с серверным API,

  • Безопасность сервера: к каким модулям имеет доступ скрипт.




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



Оф. сайт проекта: http://ift.tt/1osWrLJ

Статья на Википедии: http://ift.tt/1nogDC6

Оф. документация: http://ift.tt/1osWp6P

API Reference (не оф.): http://ift.tt/1nogDC8

Исходники примера на GitHub: http://ift.tt/1osWrLL

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.


Сайт GameTutorials сделал все свои 350 уроков по программированию игр бесплатными

image

Сайт GameTutorials, известный своими уроками по C/C++/Win32/OpenGL/Direct3D/C#/Java, открыл все свои материалы для свободного изучения. Все уроки проверены на совместимость с Visual Studio 2013, в самом ближайшем будущем ожидаются уроки по Unreal Engine и Unity Engine, кроме того, будут обновлены устаревшие уроки по OpenGL и DirectX (сейчас на сайте описана версия DirectX 9).


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


Для просмотра и скачивания уроков потребуется зарегистрироваться.


This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.


Неодимовая батарейка

Здравствуй, Хабр.

Недавно мне в голову пришла идея «пальчиковой» батарейки на неодимовых магнитах.

Долго гуглил, есть ли вообще такая штука, но ничего не нашел. Поэтому выкладываю свои мысли сюда.

Возможно, кто-то из вас когда-либо реализует мою задумку.



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


Стандартная «пальчиковая» батарейка.

Рассмотрим структуру современных батареек.

image

image

Основная их проблема в том, что со временем они разряжаются и перестают выделять энергию.

Значительно замедлить данный процесс нам помогут неодимовые магниты.

image

Моё решение.

1. Поместим в изолированный корпус ёмкость с сильным электролитом.

image

Как мы видим, заряды в электролите распределены равномерно.


2. Поместим в изолированный корпус по обе стороны от ёмкости с сильным электролитом два неодимовых магнита.

image

Как мы видим, ёмкость с электролитом мгновенно поляризуется.


3. Дело остается за малым — выводим металлические пластины непосредственно из областей с наибольшей разницей зарядов, и батарейка готова.

image

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


P.S.

Хотелось бы услышать ваше мнение. И вообще, будет ли данная система работать?


This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.


В Оксфорде разрабатывают технологию создания гибких дисплеев со сверхвысоким разрешением

A collection of still images drawn with the technology

Ширина каждого «нанопиксельного» изображения меньше, чем толщина волоса человека (около 70 мкм)

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


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


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


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


После этого ученые создали прототип ультрапиксельного дисплея, где в качестве пикселей использовались «бутерброды» из прозрачных электродов и сплава, о котором говорилось выше, помещенного между электродами. Размер площадки в этом случае составил 300*300 нанометров. При этом изображения можно делать не только монохромными: цвет зависит от толщины сплава между электродами.


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


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


Via oxford


This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.


World of Tanks Blitz: Игрушечная игрушка

Перед тем, как расскажу о впечатлениях от игры World of Tanks Blitz, не могу удержаться от небольшого вступления.

Третьего дня мне написали из пресс-службы Wargaming.net и строго поинтересовались – почему в журнале «Мир ПК» давно не было публикаций об игре World of Tanks? Я осторожно ответил, что, мол, поводов не обнаруживалось. Игра интересная, мы ее любим. Но это же не повод писать о ней минимум раз в месяц. Надо и для других хороших продуктов площади выделять.


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



Тут я нервно сглотнул слюну. Когда компания начинает говорить журналистам о патриотизме, они подсознательно чувствуют нехорошее. Ведь, насколько нам известно, Wargaming – это в первую очередь не про патриотизм, а про деньги. Причем про деньги немаленькие. Не за туесочек с березовым квасом работают программисты, и даже пиарщики, по слухам, имеют мотивацию чуть более банальную, чем возможность погонять на заветном танчике «Тип 59».


И вот когда хороший прибыльный бизнес начинает апеллировать к патриотизму журналистов, который должен выражаться в количестве публикаций о Wargaming… Мне кажется, есть в этой логике какой-то изъян. И, пользуясь случаем, предлагаю пиар-службе компании подарить мне и всем плюсанувшим этот пост танк «Тип 59». Из чувства патриотизма, разумеется.


А теперь о, собственно, главной героине статьи. World of Tanks Blitz – это новое детище Wargaming.net, работающее на планшетах iPad с версией iOS не ниже 7.0. Это, конечно, не очень справедливо по отношению к владельцам компьютеров Apple, которые ради любимой игры вынуждены ставить богомерзкую «винду». Они-то ждали, что после версии для Xbox белорусы обратят взор на OS X, но в Wargaming решили приняться за iOS. Решение, несомненно, правильное: айпадов на руках у населения сейчас сильно больше, чем достаточно мощных для запуска World of Tanks «маков». И конкуренты не дремлют. Еще в прошлом году вышла игра Tank Domination, озвученная Дмитрием Пучковым АКА Goblin. Я ее попробовал, потом еще раз попробовал, да и стер. Нет, сама-то игра вполне красивая, и озвучка радует. Однако по удобству управления она отставала от настоящих «Танков» на компьютере на пару веков. И переучиваться как-то не хотелось.




Глядя на этот экран, я сам себе завидую – все танки, груды серебра и золота… Увы, это специальный эккаунт для обзоров, и скоро он превратится в тыкву


И вот – продукт от разработчиков оригинала. Размер скачиваемых при установке файлов составляет 665 Мбайт, что по нынешним временам даже скромно. При запуске можно войти в качестве пользователя Game Center, а можно ввести свой логин из больших «Танков». Последнее, впрочем, довольно бесполезно, потому что ни уже заработанные танки, ни имеющиеся игровые деньги на планшет не перекочуют.


Разработчики обещали перенести в мобильную версию максимум возможного из полноценной игры. Я вижу, что они старались это сделать, однако компьютеры все же мощнее планшетов, плюс нельзя было ориентироваться только на владельцев новейших iPad Air и mini с экраном Retina. Поэтому графика в Blitz условно соответствует только минимальным настройкам в компьютерной версии. Видимая зона невелика, текстуры простенькие, разрушаемых объектов – кот наплакал. Пытаешься по привычке снести глиняную хижину на пустынной карте Эль-Аламейн, а она обнаруживает железобетонную твердость.





Максимальное число участников боя – семь, однако в случае с топовыми танками 9-10 уровня, которых пока у игроков немного, до боя может добраться три-четыре машины. И подождать распределения придется довольно долго – до полутора минут. Когда карта уже загрузилась, время ожидания начала боя сокращено с 25 секунд в версии на компьютере до 5. И это, конечно, очень гуманно по отношению к пользователю.




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


Игровой режим пока один – захват базы. Карты маленькие, спрятаться и затеряться на них попросту невозможно. По этой причине нет ненавидимой многими «арты» — только классические танки и ПТ-САУ.


В нынешней версии доступны боевые машины только трех стран – СССР, Германии и США. Нет никаких сомнений в том, что скоро добавят и остальные, хотя в мобильной версии различия ощутимы гораздо меньше, чем в полноценной. То есть внешне-то да, но с учетом гораздо менее гибкого управления из серьезных машин просто невозможно выжать все их достоинства.


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




Места на экране все же маловато, и порой индикаторы перекрывают основную картинку


По сравнению с тем же Tank Domination – удобнее, спору нет. Но все же до полноценной игры управление не дотягивает. Blitz, правда, старается помочь – и пушку наведет сама, и попадание засчитает, когда на самом-то деле ты слегка промазал. Даже участки вражеского танка, где у тебя есть шансы пробить броню – и те подсветит. Но в результате игра вроде и пытается казаться ТОЙ САМОЙ, а на деле принципиально другая. И потому встает вопрос – для кого же она сделана?


Матерых «танкистов» отметаем сразу. Если у вас есть достаточно мощный компьютер и вам нравится на нем играть в World of Tanks, Blitz можно даже не ставить. Оставит ощущение фальшивой елочной игрушки, которая похожа на настоящую, но не радует.




В чате народ привычно собирается во взводы, хотя не очень понятно — зачем


Если компьютера нет (такое случается все чаще), или у вас Mac, который не хочется осквернять установкой Windows, Blitz поставить, конечно, можно. С нуля, без многолетнего опыта баталий с мышью и клавиатурой, может понравиться и даже не на шутку увлечь. Я знаю живых людей, испытывающих непрерывный восторг уже больше недели. Важный плюс игры еще и в том, что она не только бесплатна, но и не слишком нагло вытягивает из игрока деньги. То есть, конечно, если доплатить, станет еще веселее, но и так неплохо.


Тех, кто планировал брать World of Tanks с собой, ждет разочарование: как и игре-прародительнице, Blitz нужно непрерывное подключение к Интернету. Скорость не критична, хватит и мегабита, а вот стабильность архиважна. По этой причине у меня не получилось играть по 3G: подключается вроде нормально, пинг в пределах разумного, но стоит пакету потеряться, как игра начинает забавно глючить. Так, играя на ИС-3, я вдруг заметил, что пушка у него стреляет чуть ли не очередями, не требуя времени на перезарядку. Потом, правда, оказалось, что и урону от нее никакого. А когда игра снова смогла подключиться к серверу, обнаружилось, что меня уже давно сожгли. Наверное, иногда по 3G сыграть все же можно, но лично мне убежать от WiFi не удалось ни с одним из операторов мобильной связи.


Общее впечатление от игры противоречивое. Лично мне она не очень нравится, потому что есть большой мощный компьютер с широкоформатным монитором Philips (соотношение сторон 21:9), и планшетная версия с ее многочисленными упрощениями не может конкурировать с World of Tanks на максимальных настройках графики (кстати, почему в WoT до сих пор не добавили поддержку мониторов 21:9 – для меня загадка. Приходится ковырять реестр)




Во встроенном магазине все готово к приходу покупателей


Но выход Blitz позволит Wargaming.net завербовать еще тысячи, сотни тысяч новых адептов, до которых раньше ей было не добраться. А значит новые миллионы долларов березовым соком хлынут в кассу патриотично ориентированной компании.


P.S. Игра заработает и на iPhone, однако я бы даже не советовал ее туда ставить. И танков не разглядеть, и управлять совершенно невозможно. По крайней мере, среднестатистической мужской рукой. Поэтому берите iPad – и нагибайте помаленьку.


This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.


Материалы MoscowJS 12

Двенадцатый митап MoscowJS прошёл 26 июня в офисе компании mailru. На встрече выступили ребята из Яндекса, Mail.ru и Tai.st. Говорили об облаках, оптимизациях мобильного веба и, конечно, расчёсках! Мы собрали видео и другие материалы события в одном посте.

Вот как это было…


Аддоны для облачных веб-приложений: взгляд разработчика

Антон Белоусов, основатель и CEO Tai.st

Чем полезны аддоны для пользователей и самих облачных продуктов, какие есть технологии и подходы к их созданию. Полезно разработчикам, либо создающим облачные приложения, либо просто их интенсивно использующим — например, Asana, Trello, Gmail и другие.


Слайды

Видео



Мобильный веб: Что же все так тормозит!

Иван Чашкин, Mail.ru Group

C чем мы сталкиваемся, когда делаем быстрое Single-page приложение. Что можно оптимизировать, чтобы увеличить «отзывчивость» приложения, повысить его производительность.


Слайды

Видео

Демо



CSScomb.js — вторая жизнь

Михаил Трошев, Яндекс

«Расчёска» — инструмент для коллективной разработки. Короткий рассказ о том, как она была сделана, для каких целей используется и куда развивается.


Слайды

Видео

CSScomb.js: GitHub



Без Бэкенда

Андрей Саломатин

Как перестать беспокоиться о серверной части приложений и сосредоточиться на опыте пользователей. Доклад об использовании готовых backend-решений в web и мобильных проектах.


Слайды

Видео

Ссылки



Фото

Фотографии с митапа собраны в нашей группе в Facebook.
Благодарности

В первую очередь спасибо выступающим за доклады! Mail.ru за помощь в организации, и, конечно, всем кто был и участвовал в обсуждениях!
Впереди MoscowJS 13!

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

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.