nepster-web

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

nginx.org/ru/docs/windows.html

jsfiddle.net/s1bf5bdL

a) Transition прекрасно работает. Просто необходимо указывать анимируемое свойство во всех состояниях:

.wrap .someclass {
    transition: all .5s ease;
    top: 150px;
}
.wrap:hover .someclass {
    top: 0;
}

b) Чтобы получился круг, вам нужно указать border-radius: 50% для квадрата:

.circle {
    width: 25px;
    height: 25px;
    line-height: 25px; // центрируем текст по вертикали;
    text-align: center; // и по горизонтали;
    border-radius: 50%;
}

Зачем разные части одного проекта помещать в отдельные ветки? Кажется, у вас неправильное представление смысла веток, которые используется в Git'е. Ветка в этой DCVS -- это всего лишь указатель на состояние рабочего каталога. И реализовать Work Flow, описанный вами на ветках Git'а не то чтобы сложновато, но зачем и для чего мучить бедный Git, который при каждом

git checkout
будет вам разворачивать поддерево то одного проекта в ваш рабочий каталог, то другого. Это во-первых, жутко неоптимально с точки зрения той же производительности, а во-вторых вы так совсем запутаетесь, тем более раз вы ещё включили в рабочий процесс слияния между этими ветками. Конфликтов слияния и трудностей таким образом можно достигнуть множество. Пожалуйста, обратите внимание на работающие подходы, используемые для разработки с использованием Git:

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

Если одна часть -- зависимость от другой, то следует подключить эту зависимость submodule'ем или вообще поддеревом (см. главу 6.7. из книги Скотта Чакона - Pro Git).

Если это всё же монолитный проект, имеющий две части, например, первая часть содержит реализацию логики приложения в "./src/core", а вторая -- пользовательский интерфейс в "./src/ui", то их и вовсе не нужно разделять.

Снова вы :)
Запомните - единица, с которой работает git - это коммит. Любое изменение в репозитории либо закомиченно, либо висит в активных изменениях. Поэтому git не мог удалить у вас файл, не сделав коммит :) Поищите по истории в каком из коммитов (в том числе и merge-коммитах) он мог удалиться.

А вообще вы явно что-то путаете, потому что checkout приводит вашу рабочую папку в состояние этой ветки, поэтому как вы могли понять что файл удалился из ветки test1, когда находитесь в ветке development - непонятно. После git co dev && git merge test1 сделайте git co test1 и скажите что происходит.

Да, и merge не удаляет изменения, а просто применяет все коммиты из одной ветки в другую.

Можно сделать 2 кнопки и скрывать/показывать их при нажатии

<div class="row">
        <div class="col-sm-6 col-md-6">
            <div class="lide-L"><div class="side-activations active" data-url="/binary/default/settings"></div></div>
        </div>
        
        <div class="col-sm-6 col-md-6">
            <div class="lide-R" style="display: none"><div class="side-activations active" data-url="/binary/default/settings"></div></div>
    </div>

$('.lide-L').toggle();
$('.lide-R').toggle();

api.jquery.com/toggleClass
Работать лучше через классы (прятать или показывать) с элементами чем менять DOM.

Если аякс ну сделайте проверку сами если проще, если класс left существует значит сделать то-то

$(this).html() и будет пустой. У вас же ничего нет внутри контейнера.
Попобуйте так $(this).parent().html()

это конфликты git-scm.com/book/en/Git-Branching-Basic-Branching-...

Там же по ссылке читайте как разруливать.

Все легко настраивается.

https://github.com/yiisoft/yii2/blob/master/framew...

Выделите скрипт начисления бонусов в задачу для Gearman. Исходя из того, что вы написали, никакой nested set (я правильно понимаю, это parent_id в записи пользователя ?) вам не нужен - вставляете в строковую колонку ключи всех вышестоящих пользователей в порядке увеличения вложенности через запятую. Обоснованность такого решения - ключи меняться не будут, иерархия часто меняться не будет, удалять записи вы тоже вряд ли будете, скорее, будете их помечать. При изменении иерархии можно эти колонки перестроить, даже простым SQL-запросом. Это даст вам возможность вытаскивать всех вышестоящих пользователей одним запросом. Ни о каких 20 секундах тут даже речи не идет, это будет занимать доли секунды.
Как только появилась необходимость начислить бонусы - отправляете задачу в очередь Gearman-а, основной пул веб-воркеров не занимается ненужной ерундой, готов обрабатывать запросы. Gearman в порядке очереди обрабатывает задачи.

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

В плане производительности, нормальный сервер работает как минимум на процессах (cgi-bin), так что все получат хотя бы поровну. Другими словами - если сервер потащит, то задержки будут (если будут) очень небольшими. Асинхронная магия - основное время CPU ожидает, а не числа дробит, отсюда конвейр сможет эффективнее построить цепочку и так далее.

Ну и потом. 10 секунд на миллион пользователей. Много. Слишком. Да и про миллион, товарищ, привираете.

soundbible.com/1258-Tick-Tock.html
Сойдет?
Вот подборка
www.audioblocks.com/search/?srch-term=Timer+Ding+&...

Тиканье в конце
www.soundjay.com/clock/sounds/clock-ticking-2.mp3
www.soundjay.com/clock/sounds/clock-ticking-1.mp3

В последнем сделал display:block; Как вариант inline-block;
jsfiddle.net/kkuXj

Или так codepen.io/roose/pen/mkoJH если тайл-текстура качественная, то и ею можно заполнить.

Я вижу только одну проблему - неравномерный background, из-за этого если блоку с текстом "Параметры игры" сделать такой же background, как у самого блока (футбольное поле?) - может появиться рамка.
Напишите, должен ли блок быть резиновым. Ну и потрудитесь выложить хоть файл с текстурой, а лучше начните что-то ваять на jsfiddle.net или на codepen.io.

Повторяю, если не обращать внимания на текстуру, то не вижу трудностей. Вот один из способов
codepen.io/iiil/pen/oLztA

jsfiddle.net/R9uq7/3

Скрипт все делает сам, если учесть, что по высоте блоки влезают.
У Вас - нельзя использовать inline-block, в этом случае появляется пробел между блоками. Не заметив этого сразу, я не мог понять, где моя ошибка. Что касается поправки (в коде я вычитаю 0.01) - насколько я понял, эта ошибка возникает из-за округления. Но с этой поправкой работает отлично, и на верстке она не видна.

Вот красивый пример )
jsfiddle.net/R9uq7/4

Собственно у вас картинка-спрайт задается фоном дива, а он имеет ширину 100% от текста и отступов. Естественно, что картинка дублируется. Либо делайте спрайты полностью вертикальными, либо ставьте картинку во вложенный спан, а не на сам родительский блок.

Если вы хотите обновить у себя
git pull
Если вы хотите залить изменения на удаленный git-репозиторий
git push

Может быть
git pull
Вам поможет?

Вам нужен центральный репозиторий, в который вы сможете загружать ваши новые правки с помощью git push (с любого компьютера), и из которого сможете загружать их в любое место, где у вас этот репозиторий склонирован, с помощью git pull. См. раздел о работе с удалёнными репозиториями в документации по Git.

Вообще говоря, git позволяет работать и в полной децентрализации, но это в общем случае менее удобно.

Так вот. Самое простое — воспользуйтесь услугами Github, хранить у них репозитории получается надёжно и недорого.

Или, если вы готовы сами отвечать за резервирование и прочее, то разместите так называемый bare-репозиторий прямо у себя же на сервере.

На практике последовательность действий, которые вам нужно совершить, описана здесь.

Вкратце — создаёте bare-репозиторий, загружаете на сервер, и указываете его адрес в качестве origin у себя в локальном репозитории (а также в любых других местах, где есть этот репозиторий — например, у вас же на сервере):

git remote add origin ssh://server.com/home/username/git/exampleproject

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

git clone ssh://server.com/home/username/git/exampleproject

При этом remote при клонировании выставляется автоматически.

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