Adamos, да, если у клиента есть пачка различных адресов в перемешку к локальным и удаленным файлам, тогда нечто похожее на "простую фабрику" действительно требуется. Но это не значит, что нужно внутри неё городить забор из операторов ветвления, так как эти источники как правило стандартизированы и по протоколу или по расширению файла можно напрямую сконвертироваться в нужное имя класса. Чтобы поддерживать еще одно расширение достаточно написать новый класс без изменения самого класса фабрики тем самым не нарушая open-closed principle. В случае с простой фабрикой нужно будет зайти и добавить еще один if или case. Такой код не SOLID, он пахнет и его сразу видно, потому что он именно так и выглядит, как свалка из всяких ветвлений. Сложно такое назвать "паттерном".
HellWalk, свой код в любом случае необходимо абстрагировать от стороннего кода. Это зависит от умений разработчика, но не от фреймворка или библиотеки. Соответственно на Yii также можно писать хороший/плохой код как и на любом другом. Я бы его не выбрал, не потому что он плохой, а потому что мне от фреймворка нужен только роутинг запросов. Но стоит отметить, что в Yii есть довольно профессиональные русскоязычные разработчики понимающие в архитектуре. Многие конечно выросли и разбежались, но выросли они именно в этой среде, вместе с этим фреймворком. Ребята из этого сообщества довольно часто выступают и рассказывают как правильно писать код. Это на данный момент самое сильное русскоязычное сообщество в PHP. И он не убогий, он монолитный, но эту проблему решают в Yii3.
Артем Громаков, попробуйте начать с дублирования кода. Размер кода уменьшиться в двое. Ну а для компании скорее дело было даже не в коде, а в том, что задача фактически не решена. Думаю там желали видеть нечто конечное на Angular/React/Vue.
Спагетти-код можно победить, архитектурные решения есть, просто это очень дорого на начальном этапе, но чем дальше, тем дешевле. С спагетти наоборот.
Поддерживаемый код это минимум десятки и сотни миллионов рублей за решение. Это привилегия крупных продуктовых компаний. Веб-студии себе такое позволить не могут, нет ни клиентов, ни специалистов.
Никита Полевой, onclose штука надежная, а сеть нет. Соединение между клиентом и сервером устанавливается через множество узлов. Соединение может отвалиться между промежуточными узлами, но при этом и клиент и сервер будут думать, что соединение до сих пор есть. Соответственно в подобных ситуациях onclose не срабатывает. Нужно использовать heartbeat. В библиотеке, которую использует автор оно есть https://github.com/websockets/ws#how-to-detect-and...
vpman, LSP это о том, что если метод базового класса например возвращает площадь фигуры, то не нужно в наследнике пытаться возвращать например диаметр окружности, это приведет к некорректной работе клиента, который зависит от данного базового класса. Все наследники базового класса должны продолжать возвращать именно площадь фигуры, а не что-то иное. Принцип никаким образом не противоречит ни одному из видов полиморфизма.
Ваш пример, про юнит-тест, html/csv и lsp изначально не корректен. Вы не в состоянии в одном юнит-тесте проверить генерацию двух различных видов отчета. Хотя бы потому, что ваш юнит-тест проверет наличие тегов в сгенерированном отчете, которых впринципе не существует в csv. Эта задача решается написанием двух разных юнит-тестов, для html отчетов и для csv отчетов. Вы же пытаетесь смешивать не смешиваемое. LSP не имеет никакого отношения к тестированию вообще. Тесты должны быть простыми, краткими и очевидными.
Создавать child::IsValidReport исключительно для целей тестирования как тут советуют не корректно и излишне. Если подобный метод никем не используется в самой программе, то он лишний и очевидно не должен создаваться, а для разных отчетов нужно просто написать разные тесты.
Антон Р., ну да, вероятно есть внутренняя утилита, которая по определенным параметрам собирает все подозрительные запросы или что-то подобное, что показывает масштаб бедствия. В крупных компаниях всегда ведется сбор всего чего только можно, чтобы понимать, что вообще происходит с проектом.
Антон Р., на авито, чтобы получить картинку с номером нужно для начала собрать так называемый phone key (pkey в запросе). Код сборки этого ключа запутан и обфусцирован. Полагаю, что время от времени его еще и меняют, чтобы переодически отваливались все работающие парсеры. Конечно можно используя реверс инженеринг разобраться как он генерится, но мне лично надоело ковыряться уже на этапе профайлинга.
Я думаю, что по логам анализируют тех кто прицепился и тащит номера. Когда таких набирается критическая масса, меняют алгоритм генерации ключа, в итоге все парсеры отваливаются, а авторы должны начинать весь процесс реверс инженеринга сначала. Не все будут это делать, так как это стоит определенных ресурсов.
Я не очень разбираюсь, но помоему функция mail внутри вызывает утилиту sendmail, а её вроде как можно настроить на использование SMTP релея. На хостинге не выйдет, но на VPS должно.
Согласен, что стоит взять готовое решение. Комментарий скорее о том, что всё же можно используя функцию mail слать письма через нужный SMTP релей.
sim3x, я вот уверен, что пошлины будут выше и значительно. Это логично, таким образом страны поощряют производство какого-либо конечного продукта из комплектующих на своей территории, а это рабочие места, налоги в казну, рост ввп и всё вытекающее из этого. Автопроизводители же не по простоте душевной строят свои сборочные цеха в различных странах.
sim3x, а импорт готового изделия будет иметь такие же таможенные пошлины, как если импортировать компоненты или дороже? Автомобили вроде специально разбирают на запчасти и завозят в страну. На месте собирают и продают, таким образом сокращая издержки, что отражается на цене для покупателя.
Макс, нет конечно. Для мелких сайтов РСУБД достаточно. Крупным нужно обрабатывать огромные массивы данных и здесь РСУБД становится уже не помощником, а проблемой. Данные необходимо шардить (делить) и оказывается невозможным использование джойнов и транзакций (между шардами) основных фишек реляционных баз данных и при этом еще необходимость писать и поддерживать свою систему шардинга на уровне приложения. Никаких плюсов от РСУБД не остается. Выбирают NoSQL, в частности mongo.
Про пинание трупов про которые тут пишут это не правда https://db-engines.com/en/ranking
В целом mongo это решение для любых современных веб-приложений, об этом было заявлено на официальном сайте. Поскольку она в духе интернета, который способен генерировать потенциально бесконечные объемы данных, а mongo соответственно их обрабатывать.
DmitryNnov, была попытка сделать такую платформу, называлась mmoconstructor.ru, но в 2017 автор её закрыл. Сейчас единственный вариант быстро поднять подобную игру это движки на php типа антибк, но там очень плохой код с различными уязвимостями.
На каждом кадре просчитывают N последующих кадров. Например 1+3. Игроку отображается 1 кадр, но посчитано уже до 3 кадра. Игроку отображается 2 кадр, но посчитано уже до 5 кадра и так далее. Игрок как-бы постоянно находится немного в прошлом. Не знаю как на unity это реализовывается, не работал с данным решением.
Sanes, я имел ввиду, что всё это должно переезжать в онлайн сервисы. Чтобы выбрать дизайн и установить на цмс веб-студия особо не нужна. Это сможет сделать конечный потребитель сам в несколько кликов. Нет смысла выкатывать в интернет типовые решения, когда это можно объединить на одной платформе.
antpv, когда происходит вызов dispatchEvent, то в очередь кладется сообщение вместе с его обработчиком. Затем оно извлекается из очереди и вызывается его обработчик, которому в качестве аргумента передается это самое сообщение. Таким образом формируется стек вызовов. Каждый вызов функции это новый фрейм в стеке. До тех пор пока стек не опустеет (не выполнится весь код) все события будут накапливаться и висеть в очереди. Как только стек опустеет, то будет извлечено следующее сообщение из очереди и сформируется новый стек вызовов. Поэтому на самом деле click срабатывает не при клике, а только тогда когда стек опустеет и это событие будет первым в очереди.