Zerstoren

Придумал сам как это дело реализовать. Может кому интересно или искать будет:

var TaskView = Backbone.View.extend({
        el: '#tasks',
        model: Todo,
        events: {
            'click > li .delete-task' : 'removeTask',
            'click > li .complete-task' : 'completeTask'
        },
        removeTask : function (e) {
            console.log($(e.target));
        },
        completeTask : function () {

        }
    });

$(e.target) и есть текущий елемент, по которому кликнули.

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

Fabric.js
Paper.js

Питон для Андроида — достаточно мозгозатратное занятие.
Я бросил эту затею, хотя иногда слежу за проектами, подающими надежду в этом направлении.

Если нужно создавать игры, то это PyGame for Android — pygame.renpy.org
Если нужно бизнес-приложения, то это Kivy — kivy.org (их гитхаб — github.com/kivy/python-for-android)

Недостатки первого:
1. проект не развивается
2. ориентирован на создание игр
3. только arm-архитектура
4. поддерживается только одно касание

Достоинства первого:
1. ниже порог вхождения — достаточно легко устанавливается (не без бубна, но легче, чем kivy)
2. куча документации по самой PyGame, которую можно использовать при разработке

Недостатки второго:
1. требует от устройства поддержку gles 2.0 (даже для простенького интерфейса)
2. везде с собой тянет библиотеку для построения интерфейсов
3. нужно постараться, чтобы установить всё это добро (кросс-компиляция и всё такое)

Достоинства второго:
1. любая поддерживаемая Андроидом архитектура
2. проект развивается
3. поддержка мультитач
4. использует наработки PyGame for Android

По поводу sl4a — он не позволяет создавать обособленные пакеты — требуется отдельно установленный интерпретатор Питона. По этой причине я его не рассматриваю.

В любом случае, стоит быть готовым к тому, что размер пакета будет минимум 3 МБ даже в случае HelloWorld — каждое приложение будет тянуть с собой интерпретатор и стандартную библиотеку.

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

Если я Вас правильно понял то:

syntax: keepalive connections;
default: —
context: upstream
This directive appeared in version 1.1.4.

или в случае fastcgi

server {
…

location /fastcgi/ {
fastcgi_pass fastcgi_backend;
fastcgi_keep_conn on;
…
}
}

Есть следующая информация:
stackoverflow.com/questions/1685326/responding-to-the-onmousemove-event-outside-of-the-browser-window-in-ie

Демо: jsbin.com/ifuma#noedit

сокет перестанет быть исправным, это очевидно. Если я правильно понял и речь про tcp/udp-сокет вида server:port1<-->client:port2.

Попробуйте как-нибудь так.
Для каждого параметра в каждом доспехе вам нужно установить что-от вроде «редкости», или «ценности». Например, на тяжелом доспехе бонус к мане будет почти ничего не стоящим, а бонус, например, к хп, будет стоить дорого.

Дальше выберите какую-то функцию, по которой цена будет расти в зависимости от значения атрибута. Если у вас атрибут сначала растет медленно, а потом «ускоряется» (например нормальная броня на 5 уровне — 10, на 10м — 20, а на 15 — сразу 100), то вам наверное подойдет какая-нибудь логарифмическая функция. Если наоборот, сначала растет редко, а потом замедляется (например на 5 уровне — 10, на 10 — 20, на 15 — 27, на 20м — 30 и т.д.), то подойдет какая-нибудь показательная функция.

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