Максим Федоров

Попробуйте следующее:

SELECT
  pd.product_id,
  d.name,
  d.discount_percent,
  d.discount_amount
FROM s_products_discount pd
JOIN s_discounts d ON pd.discount_id = d.id
WHERE 1
AND pd.product_id IN ('41987', '41988', '41989', '41990', '41991', '41992', '41993', '41994') # проверять список ид ДО более сложной проверки
AND d.priority = (
  SELECT MAX(sd.priority)
  FROM s_products_discount spd
  JOIN s_discounts sd on spd.discount_id = sd.id
  WHERE spd.product_id = pd.product_id
  AND sd.visible = 1
  AND sd.date_from <= '2018-05-05'
  AND sd.date_to >= '2018-05-05'
)

У меня только возник вопрос... А зачем везде LEFT JOIN? Разве в текущей задаче нужен именно он, а не просто join? Такое чувство, что left пишется просто по привычке.
В чем состояла оптимизация - вы строите временную таблицу, где к каждому продукту ищется максимальный доступный приоритет. Если представить, что у нас пол миллиона продуктов, вы хотим выбрать только десяток - все равно будет построена таблица по всем продуктам. Я же переместила подзапрос в where, где будет сравниваться приоритет для конкретного продукта. Судя по моим маленьким тестам, даже на малом количестве данных запрос не проигрывает, на большом количестве данных разница должна быть заметнее.

Нет, это делается не таким образом.
Работа с изображениями в php через специальный библиотеки GD/ImageMagick.
Но чтобы не возиться самому с велосипедо строением, лучше уже использовать готовые обертки.
Я советую image.intervention.io, у них отличная документация, широкие возможности по манипуляциям с изображениям, фильтры, кропы, эффекты и тд и тп. В том числе и работа с текстом, поддержка шрифтов.
Если уж хочется именно css/html шаблоны, то есть библиотека https://github.com/niklasvh/html2canvas , но тут уже вам стоит разделить логику и отображение. Мы у себя успешно использовали эту библиотеку для реализации генерации баннеров автоматически под нужный размер, используя адаптивную верстку. Сама библиотека не идеал, на практике бывают всплывают косяки и проблемы, но думаю для вашей задачи более чем подойдет.

Ну как. Записывать в таблицу к юзеру значение, например, после успешной оплаты - оно позволяет ему просматривать этот контент, и в статье проверять, есть ли у текущего юзера это значение или нет.

Вы неправильно настроили панель разработчика. У мобильных телефонов количество физических пикселей больше, чем количество «css-пикселей» в браузере. Разница выражается параметром Device Pixel Ratio (DPR) — это коэффициент умножения, сколько физических пикселей в одном «css-пикселе».

take.ms/v1Ms8

В режиме Responsive у Хрома по-умолчанию DPR=1.0 (у макбука по-умолчанию 2.0, т.к. retina-экран). Вы выставили ширину вьюпорта 540px, но у вашего телефона, скорее всего, DPR = 1.5 и разрешение в браузере соответствует 360px (540 / 1.5 = 360).

Вам надо включить отображение DPR и доработать верстку на малых экранах от 540 до 320px.

знаю одну контору со своим языком и видел куски их кода, но сам с этим не работал - бог миловал.

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

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

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

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

Нет, GitHub Pages предназначены для хостинга только статичных файлов, исполняемые файлы на сервере не поддерживаются.
Однако определять язык браузера и делать редирект можно и с помощью javascript.

<script>
var userLang = navigator.language || navigator.userLanguage; 
alert ("The language is: " + userLang);
if (userLang === "ru-RU"){
window.location.href="https://google.com/";
}
</script>

И самое главное: кто придумал слабую типизацию?

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

Динамическую типизацию придумали для того, чтобы было легче писать обобщённые алгоритмы и мета-алгоритмы, в дин. языке для обобщения кода не нужны ухищрения типа дженериков (TypeScript, C# и много чего ещё) или шаблонов/макросов (C++). В ОО-языках часто доступны и другие удобства, например смена интерфейса объекта в зависимости от его состояния (т.к. решение о возможности вызова метода/свойства объект может принимать сам).

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

Как вы пишете код на жс?

Мы не пишем код на JS, мы пишем код на TypeScript. Да, такие сейчас странные времена, когда язык со статической типизацией компилится в язык с динамической, т.к. исполнять на клиенте (в браузере) больше нечего пока.

Он же не должен быть напичкан parseInt() и !== undefined.

Не должен. Если писать на голом JS, можно а) использовать JSDoc для аннотаций о типах, и работать с типами на уровне документации и договорённостей; б) писать алгоритмы в максимально обобщенной манере, и требовать по возможности не конкретных типов данных, а значений, над которыми допустимы нужные вам операции; в) покрывать код тестами, что и спасает в динамических языках.

Чем больше проект, тем важнее статическая типизация, это нормально. JS - это язык который популярен по техническим причинам и по стечению обстоятельств, а не потому что он этого заслуживает (имхо). Очень неглупые дяди и тёти не стали бы тратить годы своего времени и кучу денег на разработку TypeScript и Flow, если бы это было ненужно.