Евгений Комаров

- Нарисовать топологическую схему
- Выбрать оборудование
- Посчитать пассивку - провода, розетки, патч-панели, шкафы/стойки
- Сформировать бюджет, получить деньги, закупить все это
- Проложить пассивку, установить активное оборудование, настроить его
- Подключить компы, настроить

PROFIT!

А Вы другого ответа ожидали? :)

Нет. Артефакт - это общее название любого файла, полученного в результате сборки. Это может быть собственно результат сборки (jar или exe), отчет о тестах, сгенерированные данные и т.д. Иначе говоря, артефакт - это нечто материальное, то что не исчезает после окончания пайплайна (в отличие от временных файлов, которые удаляются по окончании процесса)

Смотря зачем)). Я когда делаю Code Review критерии следующие:

* Безопасность:
- Каждый аргумент метода простого типа должен проверяться на тип в случае его проксирования и на граничные значения в случае обработки. Чуть что не так - бросается исключение. Если метод с кучкой аргументов на 80% состоит из поверки из аргументов - это вполне норм))
- Никаких trigger_error, только исключения.
- Исключения ДОЛЖНЫ быть человеко-понятны, всякие "Something went wrong" можно отдавать пользователю, но в лог должно попасть исключение со стектрейсом и человеко-понятным описанием, что же там пошло не так.
- Каждый аргумент (объект) метода должен быть с тайпхинтингом на этот его класс, или интерфейс.
- За eval как правило шлю на **й.
- @ допускается только в безвыходных ситуациях, например проверка json_last_error.
- Перед работой с БД - обязательная проверка данных.
- Никаких == и !=. Со swtich - единственное исключение, по ситуации.
- Если метод возвращает не только bool, а еще что-то - жесткая проверка с ===, или !== обязательна.
- Никаких условий с присваиваниями внутри. while($row = ...) - тоже идет лесом.
- Магические геттеры/сеттеры разрешаются только в безвыходных ситуациях, в остальном - запрещены.
- Конкатенации в sql - только в безвыходных ситуациях.
- Параметры в sql - ТОЛЬКО через плейсхолдеры.
- Никаких глобальных переменных.
- Даты в виде строки разрешаются только в шаблонах и в БД, в пхп коде сразу преобразуется в \DateTimeImmutable (в безвыходных ситуациях разрешено \DateTime)
- Конечно зависит от проекта, но как приавло должно быть всего две точки входа: index.php для web и console(или как-то по другому назваться) - для консоли.

* Кодстайл PSR-2 + PSR-5 как минимум, + еще куча более жестких требований (для начала все то что в PSR помечено как SHOULD - становится MUST)
- В PhpStorm ни одна строчка не должна подсвечиваться (исключением является typo ошибки, например словарик не знает какой-то из аббревиатур, принятых в вашем проекте). При этом разрешается использовать /** @noinspection *** */ для безвыходных ситуаций.
- Если кто-то говорит, что пишет в другом редакторе и у него не подсвечивается, на эти отговорки кладется ВОТ ТАКЕЕЕНЫЙ мужской половой **й и отправляется на доработку)).

* Организация кода:
- Никаких глобальных функций.
- Классы без неймспейса разрешаются только в исключительно безвыходных ситуациях.

* Тестируемость (в смысле простота тестирования) кода должна быть высокая.
- Покрытие кода обязательно для всех возможных кейсов использования каждого публичного метода с моками зависимостей.

* Принципы MVC:
- Никаких обработок пользовательского ввода в моделях, от слова совсем.
- Никаких ***ть запросов в БД из шаблонов.
- Никаких верстки/js/css/sql-ин в контроллерах.
- В моделях НИКАКОЙ МАГИИ, только приватные свойства + геттеры с сеттерами.
- В моделях разрешено использовать метод save(при наличии такого разумеется) только в исключительных ситуациях. Во всех остальных - либо insert, либо update.

* Принципы SOLD:
- Никаких божественных объектов умеющих во все.
- Если метод для внутреннего пользования - private, никаких public.
- Статические методы разрешаются только в случае безвыходности.

* Принцип DRY разрешено нарушать в случаях:
- Явного разделения обязанностей
- В тестах (каждый тест должен быть независимым, на сколько это возможно)

* Работа с БД:
- Запрос в цикле должен быть РЕАЛЬНО обоснован.
- За ORDER BY RAND() - шлю на***й.
- Поиск не по ключам (конечно если таблица НЕ на 5 строк) запрещен.
- Поиск без LIMIT (опять же если таблица НЕ на 5 строк) запрещен.
- SELECT * - запрещен.
- Денормализация БД должна быть обоснована.
- MyISAM не используется (так уж)) )
- Множественные операции обязательно в транзакции, с откатом если чо пошло не так.
- БД не должна содержать бизнес логики, только данные в целостном виде.
- Не должно быть нецелесообразного дерганья БД там, где без этого можно обойтись.

* Кэш должен очищаться по двум условиям (не по одному из, а именно по двум):
- Время.
- Протухание по бизнес логике.
Разрешается по только времени в безвыходных ситуациях, но тогда время - короткий период.
- При расчете ключей кэша должна использоваться переменная из конфигурации приложения (на случай обновлений кэш сбрасывается кодом, а не флашем кэш-сервера). В случае использования множества серверов - это очень удобный и гибкий инструмент при диплое.

* О людях:
- "Я привык писать так и буду дальше" - не вопрос, ревью пройдешь только когда поменяешь свое мнение.
- "Я пишу в vim-е и мне так удобно" - здорово, код консолью я тоже в нем пишу)) но есть требования к коду, если в них не сможешь - не пройдешь ревью.
- "Я скопировал этот страшный метод и поменял 2 строчки" - это конечно замечательно, но по блейму автор всего этого метода ты, так что давай без говняшек, хорошо?
- "Оно же работает!" - вот эта фраза переводится примерно так: "да, я понимаю, что пишу полную хрень, но не могу писать нормально потому, что руки из жо", я правильно тебя понял?))
- "У меня все работает!" - рад за тебя, а как на счет продакшна?
- "Там все просто" - не используй слово "просто", от слова "совсем". Вот тебе кусок кода (первого попавшегося с сложной бизнес логикой), где там ошибка (не важно есть она, или нет)? Ты смотришь его уже 2 минуты, в чем проблема, там же все "просто"))

* Всякое:
ActiveRecord (это я вам как в прошлом фанат Yii говорю) - полное говно, примите за исходную. По факту у вас бесконтрольно по проекту гуляют модельки с подключением к БД. Не раз натыкался на то, что в тех же шаблонах вызывают save, или update (за такое надо сжигать).
То, что используется Laravel - это печально((. Что бы выполнить требования приведенные выше, приходится "воевать" с фреймворком.

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

UPD

Формализировал данные критерии по ссылочке: https://github.com/index0h/php-conventions

Вы просто не понимаете смысл короткой записи маски.
/23 означает, что первые 23 бита маски равны единице, а последние 32-23 = 9 бит равны нулю.
Таким образом маска будет 11111111.11111111.11111110.00000000 = 255.255.254.0
Теперь разложим побитно ваши адреса:

Маска:   11111111.11111111.11111110.00000000 = 255.255.254.0
Адрес 1: 11000000.10101000.00000000.00000000 = 192.168.0.0
Адрес 2: 11000000.10101000.00000001.00000000 = 192.168.1.0

Чтобы преобразовать эти адреса в сети надо выполнить побитовый логический AND адреса с маской. Получим

192.168.0.0 & 255.255.254.0 = 192.168.0.0
192.168.1.0 & 255.255.254.0 = 192.168.0.0

Таким образом, оба адреса входят в одну сеть размера /23.
Правильное обозначение этой сети 192.168.0.0/23.

Добавь в ~/.bashrc

mkcp() {
    test -d "${@: -1}" || mkdir -p "${@: -1}"
    cp "$@"
}

Перезапусти bash

Выполни mkcp -r ~/Local/Test/* ~/Документы/Разные/2021/04/

Чаще всего, как уже написали, встречается в URL, но все же его значение чуть более шире - slug это уникальная строка идентификатор, понятная человеку (в отличие от ID) и содержащая только "безопасные" символы:
- 0-9
- a-z (общепринято - в нижнем регистре)
- символ -
- иногда еще символ _
Могут использоваться не только в URL для понятности, но и, например, в запросах к БД (в первую очередь - на уровне АПИ) - ведь
SELECT * FROM pages WHERE category="some-slug"
более понятно, чем
SELECT * FROM pages WHERE category=126.
На уровне API это выглядит как
get_pages_in_category( 'some-slug' )
или
$object->get_pages_in_category( 'some-slug' ).
В общем, это человеко-понятный уникальный идентификатор.

Создавай Event listener.
Вот пример как передать security token storage.

Ну если доступным, языком, то тогда на примере.
Например, надо выводить в лог сообщение, а также номер строки и время прошедшее с момента зарузки страницы.

Если не использовать замыкание, то надо определить следующую функцию

function log(timespan, lineNumber, msg) { 
   console.log(linNumber + " " + timespan + " " + msg;
}

и две переменные

var start = Date.now();
var lineNumber = 1;

Вызываем log так

log(Date.now()-start, lineNumber++, "один");
log(Date.now()-start, lineNumber++, "два");

Очевидно, что это неудобно.

Если использовать замыкание, то пишем так

var log = (function () {    // функция 1
   var start = Date.now();  // текущее значение сохранятся в start 
   var num = 1;             // также используется в замыкании в функции 2. 
   return function (msg) {  // функция 2 - сохраняется в var log
      console.log(num++ + " " + (Date.now()-start) + " " + msg);
   }
})();    // () -- вызываем функцию 1

Вызываем так

log("один");
log("два");

Результат

lineNumber   timespan     msg
------------------------------
1            0            один
2            1            два

Т.е. замыкание — это способ передачи данных в функцию.

Подробнее о замыканиях см Mozilla Developer Network
Примет взят отсюда

Запустить VLC из командной строки, скормив ему нужный файл и добавив опции --video-filter=motiondetect для включения фильтра детектора движения, по вкусу - --rate= для скорости воспроизведения, ну и -vv >logfile.txt - для вывода сообщений в текстовый лог, который потом предстоит изучить.

Упрощенно.

Вагрант — система управлением конфигурацией конкретной машины.
Докер — запуск изолированных процессов на машине.

Докер.
Это не виртуальная машина, а запуск изолированных процессов. Т.е., запущенный процесс думает, что он один единственный, и ничего вокруг нет. Это работает на уровне ядра Linux. Без использования виртуальных машин.

В терминологии Докера есть Images и Containers.
Image — образ, шаблон, на основе которого запускается Container.
Image строится на основе какого-либо базового образа ОС.

Container — сервис, запущенный и построенный на базе Image.

Таким образом, вы можете построить несколько образов, например, образ для Nginx, образ для PHP, образ для MySQL. Вдобавок, вы можете построить несколько образо, для каждой желаемой версии PHP, MySQL и т.п.

Каждый из этих образов будет иметь у себя в базе какую-либо ОС. Т.е., происходит изолирование окружения, на котором работает Docker.
На базе построенных образов вы можете запускать Containers, т.е., непосредственно строить рабочее окружение. Каждый запущенный контейнер думает, что он запущен один, в образе наследуемой ОС. Но на самом деле, это всего лишь отдельный процесс, работающий на уровне ядра Linux, без виртуализации. Т.е., у вас нет накладных расходов на виртуальные машины. Изолирование контейнеров выполняется на уровне ядра.

При всем этом, ваша базовая система остается чиста от устанавливаемых пакетов, свободна от неразберихи с библиотеками, версиями и т.п.

Оба инструмента хороши. Но у каждого свое назначение.

Vagrant — великолепный инструмент для конфигурации удаленных машин с нуля, VDS/VPS и т.п.
Docker — великолепный инструмент для быстрого развертывания/переконфигурации рабочего окружения, практически без изменения системы, на которую он устанавливается.

Всему блоку position: relative, а кнопке

position: absolute; bottom: 0; margin-bottom: -xx px;

* хх - половина высоты кнопки

пример

В репозиториях.

Как хочешь так и работай, в этом то и его прелесть. Он просто рисует DOM, не навязывает тебе свою архитектуру, в нем нет директив, как в любом другом фреймворке или JS-view либе, только vanilla.js. Ты просто делаешь компонент, и в зависимости от логики рендеришь его или не рендеришь. Проще пареной репы. А Flux, Redux, Flummox это уже организация данных и логики для твоего приложения. Они совершенно никакого отношения к реакту не имеют. Можно выкинуть реакт и вставить другую view либу. Можешь сделать все приложение на ангуларе, а форму логина просто нарисовать на реакте. Реакт - это просто верстка с логикой. Что-то похожее на то, как ты на PHP отдаешь HTML в зависимости от логики :) только вместо PHP - JS. И происходит это без перезагрузки страницы прямо на фронтенде, без обращения к серверу. И все по компонентам разбито) Вот такое извращенное сравнение. Хотя "знатоки" меня сейчас обосрут по полной. Как можно сравнивать PHP и React)))