Алексей Уколов

sarcasm_on
Да, в статье 99 Трудового кодекса так и написано

2)... бэк енд должен самостоятельно сделать админку при разработке бэк енд

8)... бэк енд разработчик должен сам понять и не утруждая заказчика сделать админку

sarcasm_off

Автор, проснись! Что за глупые вопросы? Какой «должен»? Как договоришься, так и будет. Конечно, заказчик хочет навалить на исполнителя побольше за те же деньги.

В MySQL, начиная с версии 8.0, вы можете использовать оконную функцию row_number():

select 
	class,
	price
from (
  select 
	  class,
	  price,
	  row_number() over (partition by class order by price) rn
  from complex
) prices
where 
	(class=1 and rn < 3) -- 2 econom
	or (class=2 and rn < 4) -- 3 comfort
	or (class=3 and rn < 2) -- 1 premium
;

Mysql online

Каждый день одно и тоже

1. Открываем официальную документацию: header();
   
2. Офигиваем, что она доступна на русском
   
3. Читаем:
   

   Помните, что функцию header() можно вызывать только если клиенту ещё не передавались данные. То есть она должна идти первой в выводе, перед её вызовом не должно быть никаких HTML-тегов, пустых строк и т.п. Довольно часто возникает ошибка, когда при чтении кода файловыми функциями, вроде include или require, в этом коде попадаются пробелы или пустые строки, которые выводятся до вызова header(). Те же проблемы могут возникать и при использовании PHP/HTML в одном файле.

4. Ищем, какой вывод попал перед отправкой заголовков
   

А так же, в конце то концов, внимательно читаем ошибку:

Cannot modify header information - headers already sent by

Вольный перевод:

Невозможно изменить заголовки, так как они уже отправлены

Читаем ошибку дальше:

output started at /var/www/u1316098/data/www/battle-mine.ru/donate/buy.php:1

Ох ниче себе, да?

передача данных началась в первой строке /var/www/u1316098/data/www/battle-mine.ru/donate/buy.php

Вам нужно переписать код так:

$data = [
    'Hi' => 1,
    'D' => [
        'type' => 'xz',
        'anything' => $any2
    ],
    'Any' => [
        [
            'type' => 'xz',
            'anything' => $any2
        ]
    ],
    'Anything' => [],
    'Minus' => [
        'Content',
        'Content'
    ],
    'Block' => [
        'dog' => "Hello-$hello2",
        'cat' => '',
        'parrot' => ''
    ]
];

if ($content != $content2) {
    $data['Anything'][] = [
        'block1' => $block2
    ];
}

$response = json_encode($data, JSON_PRETTY_PRINT | JSON_UNESCAPED_UNICODE);
// $response = base64_encode($response);

echo $response;

Тогда его можно будет закодировать в Base64

phoneDisabled.addEventListener('input', function() {
  buttonDisabled.disabled = phoneMask.unmaskedValue.length !== 11;
});

500 ошибки это слишком просто, они в логах. Гораздо сложнее и грустнее обнаружить логическую ошибку, которая висела месяцами и никто не знал. Плюс, если ты уже код научился писать и юзаешь IDE, то все 500 ошибки будут в дев режиме. Тесты нужны, в первую очередь, для фиксации функционала и тз. Я пишу только http тесты и до разработки. Чтобы руками формы по 100 раз не забивать. А то я тут одно видео видел, где ларавельщик регистрацию проверял и с каждым изменением форму заново заполнял и отправлял. По мне так низкокачественная, скучная и неэффективная разработка. С тестами все проверки автоматом, просто разрабатываешь до зелени. И потом уверенно заливаешь на продакшн и знаешь, что все работает, как задумано, а не как получилось.

тесты должны проверять что

а) прилжение работает так как нужно с правильными данными
и
б) приложение не работает как не нужно с неправильными данными, или не работает вообще

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

отлично обеспечивают регрессионное тестирование?

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

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

нет. Если имеется нормальный фреймворк для тестирования, то написать всю тестовую документацию и протестировать руками будет дольше, чем написать e2e тесты.

ИМХО, юнит-тестами, да и UI-тестами, надо покрывать далеко не всё.

Да

Представьте себе, что есть большой проект, десятки или сотни компонентов. Несколько десятков разработчиков. При всем желании, в проекте 10% текучка означает, что часто приходит человек и ковыряет компонент, про который уже мало кто помнит. А надо быстро. А в компоненте объекты с десятком методов.

Что-то поковырял, что-то изменил, но как все в целом работает - ты понятия не имеешь.
А тут бах - и хорошие юнит тесты. Уже по ним можно понять что работает, а можно и не понимать а просто запустить и делать следующую задачу.

1. support@питер.рус будет работать практически везде (но где-то может показываться punycode-адрес домена) при условии что при отправке домен корректно кодируется в punycode, могут быть проблемы с написанием на этот адрес у пользователей старых почтовых программ. поддержка@питер.рус будет работать только если все почтовые серверы и клиенты между отправителем и получателям поддерживают RFC6531/RFC6532, на практике такие адреса не используются и их не будут использовать в обозримом будущем, т.к. мгновенный переход всего интернета на UTF-8 невозможен, а что делать если респондент не поддерживает UTF-8 не понятно (аналога punycode для local-part нет). А вот использовать для почты домен питер.com я бы не рекомендовал, т.к. в таком домене используется mixed script и он не проходит по требованиям безопасности Unicode (aka TR39).
2. По RFC 952/1035 имя хоста начинается с буквы и заканчивается буквой или цифрой, внутри могут быть цифры, буквы и -. RFC 1123 дополнительно разрешает начинать имя с цифры. Но технически протокол DNS поддерживает любые символы, даже 8-битные и в браузерах могут открываться даже не соответствующие стандарту имена. Но, разумеется, правильней ориентироваться на стандарт.
3,4,5,6. С local-part все интересно, ситуация обратная. По стандарту там может быть практически все что угодно, но внутри строки в двойных кавычках (quoted-string). По факту адреса c quoted-string не используются и обычно не принимаются. Без quoted string так же очень много чего разрешено, могут быть любые цифры, буквы, символы "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "/" / "=" / "?" / "^" / "_" / "`" / "{" / "|" / "}" / "~" в любой последовательности так же разрешен символ "." Поэтому все ваши адреса допустимы. НО нельзя начинать и заканчивать local-part точкой и использовать две точки подряд (это в некотором роде баг стандарта RFC 2821/2822 и более поздних связанный с формализованной записью, который достаточно поздно заметили, стандарт RFC 821/822 разрешал две точки подряд). На практике использовать любые "странные" адреса относительно которых есть сомнения я бы не рекомендовал, т.к. не все, что разрешено стандартом по факту всеми принимается.

Строка с HTML — это просто строка текста. Без слушателей событий и свойств DOM элементов.

Вариант: держать в строке плейсхолдер, скажем пустой div с определённым id или классом, и после вставки HTML в документ, заменять тот пустой див на супер-пупер элемент-с-событиями:

const datePicker = document.createElement("div");
datePicker.className = 'datePickerInline';
// тут накладываем на элемент всякие события

const str = '<div><span>Вставляем</span><div> <div class="replace_me"></div> </div><div><p>в уже готовые html элементы в виде строки</p></div></div>';

let el = document.getElementById('element');
el.innerHTML = str;

el.querySelector('div.replace_me').replaceWith(datePicker);

План-Б: не вешать слушателей событий прямо на элементы datePicker'а, а слушать его события выше, на общем родителе: скажем, на том el, в который всё это вставляется.

Ошибка в суждениях. Дисплеи по прежнему "аналоговые" в смысле передачи света до глаза, а цифровой только интерфейс между ПК и дисплеем. Можно сделать цифровую передачу звука от ПК до колонок, но тогда ЦАП должен быть внутри колонки, а не внутри ПК(звуковой карты).