Sergei Iamskoi

background: url
color: transparent
backdround-clip: text

Используют. В зависимости от проекта конечно. Вообще тут профессионалы не причем. Просто нужно уметь использовать инструменты там где они нужны и под свои задачи. Т.е не стараться везде прикрутить бутстрап. Да с ним быстрее, но он не везде подходит. Если дизайн сделан по сетке, то не за чем писать свою сетку. Благо бутстрап модульный и можно подключить только необходимое. А если нужно сделать две колонки, то смысла подключать даже одну сетку нет никакого. С опытом это понимание придет и отпадут вопросы что используют профессионалы. Они используют то, что решает их задачи)

если именно рассматривать со стороны верстальщика - верстай так, чтобы стили нормально работали как для <a> так и для <button>. не прогадаешь. бэкэндеры разные бывают.

Смотрите, сервер не просто возвращает JSON, он возвращает тот JSON который запрашивает клиент в соответствии с определенным API.

Т.е, если клиент говорит:
- Передай мне данные о товарах
- Версия API 1.0

То сервер всегда возвращает товары в том виде, как это указано в API версии 1.0.

Если вы делаете изменения на сервере и сервер должен отдавать данные в новом виде, то вы должны лишь добавить новую версию.

Если клиент скажет скажем:
- Получить данные о товарах
- Версия API 2.0
-> Вернуть новый JSON

Но если клиент скажет 1.0, вы должны вернуть старый.

Именно таким образом разрабатывается взаимодействие клиента и сервера. Сервер один, а клиентов может быть много и обновлять клиенты можно в разное время. Главное поддерживать все старые версии API.

Искусственный интеллект — название всей области, как биология или химия.

Машинное обучение — это раздел искусственного интеллекта. Важный, но не единственный.

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

Глубокое обучение — архитектура нейросетей, один из подходов к их построению и обучению. На практике сегодня мало кто отличает, где глубокие нейросети, а где не очень. Говорят название конкретной сети и всё.

источник

Я считаю это хорошей практикой. Исключительная ситуация - это та, при которой программа выполняется не так, как ожидалось. Но, позвольте, я ожидаю, что заказ пройдет валидацию. Я ожидаю, что заказ завершится успехом. Поэтому OrderValidationException, OrderException - исключительные ситуации. Исключительной ситуацией не является, например, отмена пользователем заказа - глупо выбрасывать исключение по клику на Cancel.

Исключения гораздо глубже, чем просто "исключительная ситуация". Они помогают развести обработку ошибок по разным уровням абстракции, а использование разных типов исключений позволяет обрабатывать конкретные ошибки там, где их нужно обработать (на нужном слое). Исключения очень помогают в локализации ошибки в дальнейшем, они позволяют избавиться от простыни If .. else, проверок на null, false и прочей ереси. Они, чаще всего, делают код чище.

Но пользоваться ими стоит аккуратно, все-таки стоит разделять исключительную ситуацию и вполне нормальную, штатную ветку исполнения. Так, если заказов нет - это НЕ исключение, тут можно вернуть null - допустимо (хотя некоторые и тут выбрасывают исключение, потому что очень соблазнительно привязать код исключения к HTTP кодам). А если у вас аплоад документов, и юзер пытается загрузить файл слишком большой, то это уже исключение.

Проблема Composer'а с потреблением памяти при обновлении с большим количеством зависимостей - весьма известная, достаточно посмотреть в их issue tracker (1,2 и множество других).

Jordi Boggiano, один из авторов Composer говорит (к примеру здесь) что проблема будет принципиально решена во второй версии, которая сейчас в разработке.

Aside note: обычно команды, модифицирующие список пакетов (и требующие для этого кучу памяти) стоит запускать только при разработке (т.е. к примеру на вашей локальной машине), для деплоя проекта необходимо использовать composer install, а он много памяти не требует.

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

<div v-for="cat in categories" :key="cat.id">
     <app-form :category="cat" /> //тут весь компонент у которого будет свой show
</div>

Можно конечно еще через event.target или ref, но как по мне это уже будет костыль, не самое элегантное решение

Самый простой способ - завести SSH ключ чтобы логиниться без пароля, и в пхп написать
$out = shell_exec("ssh user@host 'df -BM'");
ну и распарсить потом $out;

Это делается для ускорения работы. Стандартная функция со слешем быстрее вызывается ибо чётко задан неимспейс.

Но, по факту, смысла в этих мизерных оптимизациях нет. Только внешний вид кода портит. В хайлоад-проектах узкое место это не пхп.

Итого:

Есть ли от этого какой-то прок?

Нет.

Этого требуют какие-то соглашения по стилю кода?

PSR -- нет.

Many to many relation

Тут нужно понять сам принцип миграций. Первоначальный сетап базы можете запилить 100 таблиц (если у вас есть готовая структура и вы хотите просто перевести на ее миграции и не таскать все время дамп) в одном файле это дело вкусовщины если файл покажется длинным можете разбить его по функциональности в этом файле миграции все что связано с кастомерами в этом с продуктами и тд если и эти файлы тяжело просматривать тогда каждая таблица один класс миграции.
Но потом класс миграции должен появляться на каждый чих в бд в частности пять человек пилят задачи и если в рамках задачи надо что то поменять в бд делают класс миграции. Чтоб после обновления локальных копий комманд не искать актуальную версию бд а выполнить миграцию.