Laravel по-русски

Всегда так было:

; This directive determines whether or not PHP will recognize code between
; <? and ?> tags as PHP source which should be processed as such. It is
; generally recommended that <?php and ?> should be used and that this feature
; should be disabled, as enabling it may result in issues when generating XML
; documents, however this remains supported for backward compatibility reasons.
; Note that this directive does not control the <?= shorthand tag, which can be
; used regardless of this directive.
; Default Value: On
; Development Value: Off
; Production Value: Off
short_open_tag = Off

short_open_tag иногда включают локально, но всегда рекомендовалось использовать полную версию. Ну, и на <?= ?> это не влияет, она всегда работает.

Как раз логично делать через nginx, двумя блоками server, первый из которых работает для myexample99.com и редирект не делает, а второй работает для всех остальных, с редиректом.

Вообще не обязательно для этого использовать WebSockets. Сегодня нынче их везде суют, не зная про старый-добрый EventSource - "односторонний" аналог, который не требует ни Node.js (на котором так любят писать сервера WS), ни особой настройки сервера, ни особого протокола, а его API просто и понятно:

var es = new EventSource('foo.php')
es.onmessage = function (e) {
  alert(e.data)
}

На стороне сервера:

<?php
header("Content-Type: text/event-stream");
header("X-Accel-Buffering: no");  // если у вас nginx

while (true) {
  echo "data: hello!\r\n\r\n";
  ob_flush();
  flush();
  sleep(5);
}

И все.

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

new EventSource('online.php')

На сервере - как я написал выше, кидать в поток пустые сообщения каждые N секунд, чтобы избежать таймаута. И пока скрипт крутится - считать клиента в онлайне. Через register_shutdown_function() на отключение можно как-то отреагировать, сбросить там флаг в БД и пр. Даже если у клиента целый день открыта страница в фоне и он с ней ничего не делает - поток будет работать.

Особое достоинство в том, что EventSource сам переподключается, если соединение рвется (ушел в ждущий режим, в метро и т.п. WebSockets нервно курит в сторонке при реализации подобных задач.

У EventSource еще много интересного - советую почитать MDN: https://developer.mozilla.org/en-US/doc … ventSource

Сложно сказать по описанию без кода, но, вероятно, подойдет способ с учетом уже обработанных индексов. То есть если массивы без ключей (цифровые ключи по порядку), то для каждого можно запоминать последний индекс, который был обработан (начинается с 0, после прохода по циклу = count($array) и т.д.), а в каждой итерации сверять итерируемый индекс с запомненным и пропускать уже обработанные.

Проще использовать два массива - старый и новый, и писать только в новый. Или данных много?

"Кило" это просто приставка, обозначающая как раз 1000 ("кило"метр, "кило"грамм). Но в ИТ в комбинации с "байтом" она традиционно обозначает 1024, т.е. степень двойки. Формально это пытались исправить, введя "киби" вместо "кило", "гиби" вместо "гига" и т.д. (см. Википедию) - но, насколько можно судить, это совершенно не прижилось и народ продолжает использовать "кило" как 1024. Получше ситуация с сокращениями (как "кг" для "килограммов" - "кб" / "Кб" / "КБ"): заглавная "К" (и "М", "Г" и т.д.) используется для "кило как 2^10", а строчная "к" - для "кило как 10^3". Таким образом, 1 кБ = 1000 байт, 1 КБ = 1024 байта. Кроме того, есть сокращение Ки (Ki) - 1 КиБ (1 KiB) = 1024 байта, это как раз исходит из единицы "киби" (kibi - кибибайт). С формальной точки зрения калькулятор Google прав, он все это знает и в этом можно убедиться, введя "киб" или "kib" вместо "кб"/"kb".

Тем не менее, надо констатировать, что в современном мире единицы измерения в байтах используются как ни попадя и обычно все-таки под "кило" понимается 1024, вне зависимости от. "кб", "КБ", "Кб", "кБ" - все это 1024 байта. Особо занятно, что иногда "б" вовсе убирают и тогда без контекста не понятно, имеется в виду байт или что-то другое (например, число строк в таблице): "5к", "10М".

Зачем так сложно? Подзапрос не нужен, JOIN'ить таблицу можно саму на себя.

select  count(*) as cnt,
	u.firstname,
	u.lastname
from users 
join users u on users.firstname = u.firstname and users.lastname = u.lastname 
group by u.firstname, u.username
having cnt > 1

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

Проблема только в том, что логи 1) обычно отключают, т.к. они тормозят систему, 2) [должны быть] не доступны для чтения скриптам.

Если изображение маленькое, то ссылаешься на скрипт (маршрут), который увеличивает счетчик где-то в БД или на диске, после чего делает readfile('pic.jpg');. Если файл большой, то без помощи веб-сервера не обойтись - скрипт увеличивает счетчик, а потом делает нечто вроде header('X-Accel-Redirect: pic.jpg'); (это для nginx). Это позволит клиенту использовать мультипоточную загрузку/догрузку, Expires и прочее. Для мелких файлов это не так важно, поэтому там можно и через readfile() отдавать.

Он ситуации зависит. Если их в БД изначально нет, то странно их вначале туда вставить, потом обработать, а потом извлечь (если памяти веб-сервера хватит, конечно). В PHP вполне быстрые стандартные функции, это все-таки Си; конечно, лучше не делать то же самое самим PHP, как человек тут выше делает в цикле.

Для гарантий нужно использовать индексы (UNIQUE), вне зависимости от того, как ты обрабатываешь записи - через SQL или PHP, ибо два клиента могут одновременно выполнить один и тот же SQL и получить дубли.

С этим я спорить не буду, так как все-таки очень зависит от ситуации. Вот еще два аргумента:

1. Чем "круче" SQL, тем меньше он переносим, а PHP - один на всех. При гипотетическом переносе проекта с MySQL на PgSQL (например) работы сильно прибавится. Да и отлаживать кучерявые SQL - так себе удовольствие.

2. PHP выполняется на стороне бекенда, а SQL - на стороне БД. В проекте вполне можно представить несколько независимых бекендов, но вот несколько независимых БД - с трудом (ибо это уже будут разные проекты). Так что решая задачу на стороне PHP ты нагружаешь (а то и блокируешь) только один бекенд, а не БД и все бекенды соответственно.

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

Или увеличить memory_limit в php.ini.