А что не получается? Проверяйте, отправляйте.
В ReactPHP есть возможность зарегистрировать функции для асинхронного выполнения с указанием интервала проверки. Используйте этот функционал.
order_worker_statuses.order_id -> orders.id
orders.order_worker_status_id -> order_worker_statuses.id
Таблицы связаны перекрестно друг с другом. Непонятно зачем нужны такие связи.
weranda, первая схема выглядит ошибочной, перекрестные ссылки - это ужас. И зачем разбивать связь один к одному на 2 таблицы? Для этого должно быть какое-то обоснование, не вижу такой необходимости.
Из вашего описания статусы должны выглядеть так:
Новый
В работе
Проверка менеджером
Проверка руководителем
Готово
По этим статусам заказ идет последовательно. Плюс статусы для нестандартных ситуаций, например "Брак".
В этом случае у заказа всегда будет только 1 статус. В вашем варианте, для проверок нужно будет делать подстатусы, а значит дополнительные условия в коде, и усложнение всего workflow.
В основном безопасники занимаются бумажной работой, регламенты, соблюдение законов и т.п.
Есть довольно редкие случаи, когда они ищут уязвимости, здесь нужно хорошо знать языки программирования, но в ином аспекте нежели разработчикам. И кстати, это довольно монотонный труд, примерно такой же как у тестировщиков, с разницей, что идет перебор на устойчивость к известным уязвимостям. И уж точно, не идет речи о креативе в поиске новых способов взлома, даже в компаниях "белых хакеров", разве что, может быть в органах гос.безопасности. Поэтому причем здесь Computer Sience? Или "настоящее ООП"? Разработка здесь вообще не причем. Не нужно изобретать градиентный бустинг, наплевать какое ООП правильное, важно знать как тот или иной код можно использовать не по назначению. Равно как и системное администрирование, безусловно знать нужно и сети, и различные продукты, но ровно в той плоскости, которая требуется для взлома. Как минимум, генерация запросов вручную, с подменой необходимых параметров. Как максимум, знание уязвимостей различного ПО по версиям и умение их эксплуатировать.
Но все перечисленное встречается исключительно редко, а в общем случае - смотрите первое предложение.
Sinus_314, толстые контроллеры - это не антипатерн, это ошибка при использовании MVC. Просто потому, что это рушит весь смысл MVC. И да, вы можете не использовать MVC, и когда пользовательские запросы приходят одинаково, обработка их одинакова, а вывод тоже всегда один и тот же, то проблем не будет.
Yurii Diduk, я больше не про технологии, а про процесс CD, как он проходит, что и как делается, что автоматически, что нет. Что делает указанный пайплайн и т.п.
Прочитать можно в доке GitHub. Сейчас глянул туда, вероятно лучше это реализовать через status checks. Вероятно - потому как все равно не понятно, что конкретно делает пайплайн и какое у него место в деплое.
Расскажите, как у вас устроен CD, и CI если есть связь.
Если имелось ввиду просто, чтобы нельзя было смержишь пулрек, если не отработали, к примеру, тесты. То достаточно сделать Jenkins обязательным ревьюером и пусть он ставит апрув или не апрув по результатам проверок.
Антон Швец, в гите нужно хранить исходники. То что разное на разных машинах - это не исходники. Сделаете вы то, что хотите через хук или гитигнор - безразницы, вы нарушите работу проекта. Т.к. получится что в гите у вас набор кода, который не соответствует тому, что вы разворачиваете. Как вы будете что-то разрабатывать и тестировать, если код везде различается?
Роми, в ARPANet использовался протокол IP, прямого отношения к протоколу ARP нет, просто похожие абревиатуры. Основные запросы ARP это чтото вроде "Кто знает ethernet-адрес для такого-то IP?", он организовывает связку ethernet-протоколоа и IP-протокола.
В принципе внутри локальной сети можно использовать любой протокол для адресации, хоть свой придумайте, главное чтобы ОС внутри сети понимали его. Разве что коммутаторы сейчас все умные, и разбирают пакет на уровне ethernet-протокола, простых повторителей уже наверное не найти.
Ethernet-протокола достаточно, чтобы адресоваться внутри сети, т.к. есть адрес отправителя, и есть адрес получателя. Но даже локальные сети обычно сегментированы, неговоря уже про интернет. Между сегментами стоят шлюзы, и вот тут нужен IP протокол, чтобы не слать пакет во все сегменты, мы определяем нужный по подсети протокола IP. Формируя пакет в нем указываем IP адрес целевой машины, а вот ethernet-адрес будет машины-шлюза. Коммутаторы опираясь на ethernet-адрес прокинут этот пакет до машины-шлюза. А она уже ориентируясь на IP-адрес отправит пакет в нужный сегмент сети и назначит уже другой целевой ethernet-адрес пакету, соответствующий нужной машине.
Разумеется это все может быть гораздо сложнее, но главное что все завязано на протокол IP. И выбирать можно только между IPv4 и IPv6 (там где он поддерживается).
С DNS все проще, соответствие доменного имени конкретному ip вы можете брать хоть из файлика. Но что у Васи в интернете есть домен page1.vasya.ru может оказаться знает только DNS который установлен у Васи. DNS "точки" знает где искать DNS сегмента ru, DNS ru знает где искать vasya.ru. Поэтому опять же придется взаимодействовать через глобальные DNS (разумеется обычно это все кешируется), либо напрямую запрашивать Васин DNS.
Тимур Мамедов, вам нужно не данные подбирать, а написать код так, чтобы он не ломался при любых данных, даже если делаете проект только для себя. Используйте подготавливыемые запросы, там все проще, чем кажется.
Так уже точно не будет работать. Я имел ввиду, что в переменной description присутствует кавычка, это и нарушает синтаксис выражения. Посмотрите на ваш запрос после подстановки переменных и все станет понятно.
Ещё раз, используйте подготавливыемые запросы, это решит вашу проблему, а заодно даст защиту от sql-инъекций.
Проанализируйте сетевые пакеты, кто кому и что отправляет в каждом из случаев. Думаю, станет понятно где проблема.
Тупо, навскидку, ваш сервер обрабатывает, только get запросы, что вы видите в браузере, но не обрабатывает post, а передача данных скорее всего идёт через него. А может версия http или ещё что. И что значит не видит? Какая именно ошибка?
Roman Kitaev, да, резонно, хотя охлаждение более актуально для игр, там действительно это проблема. Для разработки, тем более, когда не нужно собирать и компилировать что-то тяжёлое это уже не так актуально.
Посмотрел сейчас недорогую msi, там seq read около 2Гб. В играх, когда при старте заканчивается большое кол-во последовательные данных 3Гб вероятно будет шустрее. Но при разработке вряд ли чем-то поможет.
Тут "как пример" не вариант, разумеется у маков хорошее железо, но и цена не низкая. Поэтому не факт, что это оптимальный вариант по цене качеству.
И все очень сильно зависит от задач. Для разработчика крайне важна оперативка, 16Гб уже маловато. Терпимо, но я бы брал больше. Разумеется для того, кто пишет не в нотпаде, и вагранты или виртуалки для него норма. Проц мощнейший не обязателен, ну не собирает фронтендер код из исходников, компиляция ts в js не в счёт, нет тяжёлых вычислений. Быстрый ssd всегда хорошо, но я бы смотрел на random read, это будет полезнее, для той же индексации в Storm.
Это лишь мой взгляд, но знаю, что у каждого фронтендера обязательно должен быть мак.
Roman Kitaev, экран каждый выбирает по душе. По мне, классная матрица, но 13 дюймов, очень маленький экран. Тачпад важен тому, кто не пользуется мышью. Алюминиевый корпус это понтово, но к решению задач, обозначенных автором не имеет отношения. Ssd в 3Гб это прекрасно, но не уверен, что все модели оборудованы им, не увидел у Apple такого описания, равно как и у других брендов. Кроме того, а зачем автору 3Гбс в seq read? Где ему ежедневно понадобится высокая скорость последовательного чтения? Тут уместнее смотреть random read.
А вот кол-во оперативы гораздо важнее, вариант с 8Гб,который он рассматривает, вообще не вариант для разработки.
Владимир Коротенко, нет никакого совершенного кода, в принципе. Есть компромиссы, есть специализированные решения, а есть просто ошибки.
Бизнес не пишет код за программиста, бизнес не заставляет писать с ошибками, бизнес не придет и не скажет, у вас тут нет такой ошибки в коде, нужно ее срочно сделать. Да, бизнес хочет быстрее и дешевле, но код он не пишет. Ну нельзя постоянно во всем винить бизнес.
Но, такое возможно тогда, когда тимлид не умеет взвешивать риски и требует делать "тяп-ляп". Стоит ли говорить, что из таких контор нужно бежать как можно быстрее.
Безусловно есть решения, где нет api, в этом случае необходимо его сделать, либо иную прослойку. Да, можно забить, по принципу "и так сойдет", свалив все на бизнес. И через год или 2, идти к бизнесу объяснять, что нам нужно где-то полгода, чтобы переделать весь наш код, ведь в коробочном решении изменилась версия и нужно все переделывать, т.к. написано дохрена и больше запросов лазающих напрямую в базу. Думаю, бизнес сделает выводы о компетенции специалиста, и будет прав, а крики "меня заставили" пропустит мимо ушей.
В общем, можно и так, но я бы не стал.
Владимир Коротенко, здесь СУБД MySQL, если мигрируем, то нужно мигрировать. Легаси - это легаси, а ошибка хоть в старом коде, хоть в новом остается ошибкой и ее нужно править. Коробочное решение имеет свою БД, лазить в чужую БД это очень плохое решение.
Как бы исторически не сложилось, какой бы код не попал в поддержку, чем раньше ошибка будет исправлена, тем меньше последствий, тем меньше работы в будущем, т.к. оттягвание решения лишь усугубляет. Это тоже из опыта.
Не пытаюсь убеждать, что только так, но автор вопроса должен понимать, что за сиюминутные костыли может быть потом очень больно.
Владимир Коротенко, да, бывает сложнее, но здесь то, все просто. Во вне может хранится как угодно, хоть латинскими цифрами, но, убить производительность запросов, просто потому, что было лень подготовить данные - это странно.
Вот спросит вас джун на кодревью: "сеньер-тимлид-архитектор почему здесь число хранится как строка, тем более что уже есть запрос на подсчёт суммы?". Что вы ему ответите? Не было времени. Но он же ответит, что это 1 строчка и будет прав.
В реальности далеко не всегда делаешь по учебнику, но в любом случае всегда должно быть обоснование почему. Можем сделать проще и быстрее - отлично, но должны быть уверены, что сможем дальше масштабироваться и это не нанесет вреда в будущем. Подход “здесь и сейчас" как правило провален, т.к. съэкономленные 6 часов, в будущем превратятся в 6 недель, а то и месяцев разгребания последствий ошибки в архитектуре.
И это не дело рефакторинга, это просто ошибка, т.к. изначально видим, что решение приводит к деградации производительности и не имеет никаких плюсов.
FanatPHP, всегда готов послушать другое мнение, понять, что в головах у других. А иногда бывает даже полезно, когда оказывается, что я даже в очевидных вещах ошибался или не знал что-то.
В ReactPHP есть возможность зарегистрировать функции для асинхронного выполнения с указанием интервала проверки. Используйте этот функционал.