Walt Disney

обёртки это div с классом ct?
На них указывают якорные ссылки,
нужны они, что бы срабатывали правила содержащие :target,
в друг друга они вложены для того что бы все элементы внутри низ были вложены во всех них и можно было задавать одинаковые каскадные правила типа:

#t4:target .p1,
#t5:target .p1
background black

"~regexp~iu" - нужно добавить модификатор u это значит utf8.
и соответственно проверить, что исходник и приходящая на проверку строка в utf8

Если рассылка белая, то sendy.co

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

В общем случае суть где то такая:
1) на сервер отсылается запрос "посадить_укроп_в_грядке_с_координатами(5,5)"
2) Сервер, запоминает состояние грядки в координате 5,5 и присылает ответ, что всё ок, расти будет 300 секунд.
3) Клиент запускает таймер на 300 секунд, по которому будет меняться анимация того как растёт укроп
4) По истечению 300 секунд клиент переводит укроп в координатах 5,5 в состояние "готов к уборке"
5) Пользователь жмёт собрать укроп, на сервер уходит "собирать_урожай_в_координатах(5,5)"
6) Сервер проверяет, что прошло достаточно времени (т.е. 300 секунд +/- лаги) и даёт ответ, что да можно собирать укроп. И сохраняет состояние грядки как пустая, а укроп перекидывает в амбар.

Так же стоит отметить, что секунда на сервере, ещё кое как, близка астрономической, но вот 1 секунда на JS в браузере может быть какой угодно.
Поэтому никто секунды не считает, считают дельту по времени.
Т.е. создают объект на который в котором запоминаются таймауты в секундах, текущее время и функции которые будут вызваны по их истечению. Потом setinterval/setTimeout допустим раз в 1 сотою секунды проверяет дельты текущего времени к сохранённым в этом объекте, и если дельта больше чем таймаут то дёргает функции обработчики.

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

Просто скачайте jar для вашей темы или соберите его.

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

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

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

Ну или у вас квази-монополия продукта на соответствие каким то ФЗ.

1) можно просто по крону выполнять в консольную команду типа cut access.log -d' ' -f 7 | sort | uniq -c и сбрасывать результат в базу.
2) мемкеш не будет удобен, рано или поздно он начнёт сам удалять счётки, по тайм ауту или по нехватке памяти и это надо иметь ввиду, соответственно и решение должно быть рассчитано на потери. Т.е. например если в мемкеш ключ пуст, то забираем значение из базы и кладём в него, для отображения тоже используем значение из мемкеша, при запросе страницы инкрементируем ключ в мемкеш. А вот значение в базе обновляем например из методом описным в первом пункте. Соответственно играясь с временем жизни записей в мемкеше и частотой парсинга логов будем регулировать возможные лаги в значениях счётчика.
3) парсинг логов можно заменить на очереди типа rabbitmq
4) в большинстве случаев можете не париться и вынести счётчики в redis.io

Историческая причина:
C# и .NET в целом это долгие страдание MS в попытках потеснить JAVA SUN . Тут дело в том что они сначала делали свою JAVA (J++ MSJVM) но проиграли долголетние суды против SUN. Если бы они не проиграли, то есть вероятность, что .net не появился бы.
Когда названные компании отстраивали разработку MS ничего не мог им предложить, кроме неопределённой судьбы своей версии JVM.

Прагматичная причина:
На каждый чих нужно лицензировать что то из стека MS технологий/продуктов, даже если это небольшие деньги на фоне оборота, то это не удобно ибо таких чихов у них 100 500 в день.

Практическая причина:
Для этих компаний очень болезнен vendor lock. Отчасти конкурентные преимущества этих компаний построены на подпиливании открытого ПО, на MS стеке это не возможно.

https://developer.mozilla.org/en-US/docs/Web/API/D...

$(document).keyup(function(event){
  var $srchForm = $("input#search-form"),
  $lnk_logo = $("a.lnk-logo");
  if (event.keyCode == 9 && document.activeElement.tagName == 'BODY') {
    $srchForm.focus();
  }
});

Разработка в команде на ООП намного проще.
Соло на ООП обычно гораздо проще разобраться, что сам написал месяц, год, два, три назад, точнее даже наоборот позволяет что-то поправить не поломав всё или выдрать не разбираясь как оно работает в целом. За это и любят.

Мой моральный порог без ООП где-то строк 500 кода, но чаще и того меньше.

Потому, что модно.

У нас года полтора назад ничего лучше чем мегафон вот с этой опцией не нашлось. Там что то около пары рублей в день набегало.

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

Туристические симки там дорогой стартовый комплект, европейские там муторно с покупкой не резидентам.

У производителей тех трекеров о которых вы говорите индивидуальные договора с операторами.