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

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

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

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

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

Юниты кстати не всегда могут это обеспечить.
Вполне обычная ситуация - все функции и классы работают идеально, но в приложении всё ломается, тк кто-то криво зарегал их в 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, в который всё это вставляется.

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

Чтобы узнать, почему не работает соединение или запрос, надо настроить РНР так чтобы он отображал ошибки, а mydsqli - чтобы оно бросало исключения.
То есть код должен выглядеть вот так

<?php
// видеть все ошибки!
ini_set('display_errors',1);
error_reporting(E_ALL);
 // подключаем настройки
require_once 'connect.php';

// включаем режим информирования об ошибках
mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);
// подключаемся к серверу
$link = mysqli_connect($host, $user, $password, $database);
// не забываем установить кодировку, чтобы не было ошибок с кракозябрами
$mysqli->set_charset('utf8mb4');
   
// выполняем операции с базой данных
$query ="SELECT * FROM foo";
$result = mysqli_query($link, $query);
// дальше делаем что нужно

// и кстати, в большинстве случаев закрывать подключение не надо

ЗЫ. На боевом сервере ошибки на экран выводить конечно не стоит, а их надо писать в лог (собственно, именно поэтому все эти die - это ужас). И на боевом сервере display_errors надо отключать, а log_errors наоборот - подключать.
Если совсем не можешь найти, где у сервера висит лог ошибок, можешь задать свой собственный, с помощью функции ini_set('error_log','/путь/к/файлу');. Но только размещать его надо разумеется в папке недоступной пользователям сайта


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

Если разобраться, то код or die("Ошибка1 " . mysqli_error($link)); очень смешной (это не к тебе претензия, никто не ожидает от тебя понимания таких тонкостей, которые не то что новички, а половина здешних "кураторов" не понимают).
Что тут происходит?
слово or die (которое на самом деле вообще нельзя никогда писать) пишут тогда, когда ожидают что в переменной $link будет значение false. Но если в $link будет false, то тогда её бессмысленно подставлять в mysqli_error. Именно поэтому для получения ошибки соединения в мускули есть отдельная специальная функция.

Но как я говорил выше, применять её не следует, как и or die.

Ты набрел на сайт машинного перевода ответов со стаковерфлоу.
В оригинале так:

1. Arrays store homogeneous data. Collections store both homogeneous as well as heterogeneous data.
По этим ключевым словам (java homogeneous heterogeneous data) гуглится такой ответ https://stackoverflow.com/questions/36700490/what-...

2. In Arrays, there are no underlining data structures, whereas Collections have underlining data structures.
Думаю тут опечатка, имеется ввиду underlying, т.е. "коллекции основываются на структурах данных". Для Map это, например, хэш массив, дерево, trie, для List связный список, массив и т.д.

Если еще актуально, я нашел решение данной проблемы тут : https://github.com/webpack/webpack-dev-server/issu....

Кратко, проблема заключается в .browserslist .
Нужно в webpack.config.js добавить данную проверку:

target: process.env.NODE_ENV === "development" ? "web" : "browserslist",

Как-то так)

А также в Webpack 5 изменился вызов dev сервера.

"start": "cross-env NODE_ENV=development webpack serve"

Используй Guzzle без Laravel-обёртки в конкурентном режиме.

Посмотрите в сторону https://github.com/spatie/laravel-query-builder
И фильтры по полям, и связи по требованию.

Один мальчик не зная javascriipt-а приступил к фреймворкам, нашел себе работу, дорос до тимлида, создал свои курсы, так и не поняв, что он не знал javascript и совершенно не был готов к изучению фреймворка. А время то не вернешь.

PS Если говорить серьезно, то доказательство существования пудинга в его вкусе. Если пишете работающий код на js - значит знаете на уровне, достаточном для фреймворка. Процесс познания почти бесконечен. Поэтому какой-то точки, где можете сказать "Да, теперь я знаю" не существует. просто получайте удовольствие от изучения и программирования и не парьтесь знаете вы что-то или нет.

Сейчас у меня каждый компонент помещает результат в собственный скрытый input, но как-то эстетически мне это не нравится...

И почему же? Я тоже так делал. Но чаще даже отдельный скрытый инпут не нужен.