Как всегда, дьявол кроется в деталях. Разделить код по папкам и завязать их в ядро не самая сложная задача, у вас она поучилась хорошо. Нужно еще не забыть тесты разделить по модулям.
Но вот как потом научить эти модули друг с тругом работать так, чтобы не росла связность?
Я предложил бы уже на старте добавить линтеров на проверку нарушения слоев, пусть это будет https://github.com/deptrac/deptrac или же на уровне psalm можно проверять целостность слоев. Иначе будет каше и беспорядочные связи в модулях
Проблемы с перезагрузкой страницы нет, если у тебя быстрый интернет и ты все файлы статики можешь заново загрузить. Проблема на медленном мобильном интернете, когда чтобы получить основной контент, ты снова ждешь и грузишь шапку, стили и тд. Для мелких сайтов разницы нет, для больших гигантов это это экономия на запросах к серверу для получения статики и нагрузки на бекенд для генерации меню и прочих динамических вещей на сайте.
Не проще реализовать все через centrifugo. Она написан на go и умеет держать много ws подключений. А из пхп отправлять события/сообщения через gRPC в centrifugo. Не думали над таким решением?
Обожаю такие статьи, заголовок "... в 500 строк", но по содержанию понимаешь, что чтобы написать эти 500 строк, нужно изучить матан, теорию вероятности, 3Д моделирование и еще кучу всего. Мое уважение автору за старания и отдельный лайк за демонстрацию результата в 3Д!
Звучит логичино и аргументы понятные, но переписать все на %подставь_свтой_язык% для бизнеса означает потерять кучу времени и не факт, что это окупится, а выгоды мало для бизнеса. И сейчас все гиганты, которые начинали с PHP (ВКонтатке, facebook, badoo и тд), полностью не переезжают на другие языки, хотя денег найти на рынке Go-шника и обучить у них точно хватает. Они перевозят лишь частями свои сервисы, разгружая узкие места. Именно поэтому все чаще встречаются вакансии PHP+Go, чтобы умел и админку на PHP сделать и API под высокие нагрузки на GO накидать.
Мне уже несколько рекрутеров в ЛС писали с предложениями frontend, так как в своем профиле указал, что знаком с vuejs и angular. Так что рекрутеры активно это дело парсят и смотрят точно. При этом читают также, как и ваши резюме между строк (указал в резюме, что знаешь Java, предложили вакансию на JavaScript)
Спасибо за полезную статью. А какие метрики вы собираете на этапе сопровождения? Очень интересно узнать про сбор количества репортов багов или обращений в тех поддержку.
Видел чат в телеграмме, вступая в который бот присылает картинку и просит ввести капчу. Потом все удаляет из чата, чтобы не засорять историю чата.
Но основная проблема, что другие участники чата тоже все видят и им уведомления зря приходят. Вот бы как в Slack (там возможно писать сообщения от бота только для конкретного пользователя), бот пишет сообщения, которые видишь только ты.
Судя по документации, у telegram есть возможность отслеживать новых участников в группе (описание объекта Update) и там есть поле message.new_chat_members[].is_bot. Почему нельзя по этому параметру отметать ботов?
P.S. у нас в ulskPHP в телеграм есть бот Ильич, который публикует новости о PHP и шутки в канал, умеет здороваться и откликаться на сообщения пользователей. Именно по параметру is_bot я настроил ответ бота, чтобы он не отвечал на самого себя и других ботов.
Я не пишу на .net, разрабатываю проекты на php, но каждый раз задумываюсь над этими и другими сотнями мелочей. При этом каждый новый проект ты начинаешь с идеей «Напишу проект лучше и круче по архитектуре, чем прошлый», а спустя 3 часа ловишь себя за копированием каких-то классов из старого проекта в новый. Да, ты закладываешь структуру нового проекта чуть лучше, но в ходе работы над проектом всплывают другие косяки, которые ты уже закрывал в старых проектах, но в этом не можешь, так как заложил все «круче» и «лучше». И вот ты снова пишешь неидеальный проект, круг замкнулся.
Возможно будет лучше. Я бы с радостью пользовался классом Array, который делает нормальный порядок аргументов для привычных методов. А то сейчас это просто мешанина, где нужно помнить каждый аргумент в каком порядке передавать. Пример:
В УлГТУ есть и магистратура, в которой можно продолжить образование по профилям «Методы и устройства обработки сигналов и изображений» и «Сети, узлы связи и распределение информации».
В магистратуре УлГТУ есть и более IT-шные специальности:
Очень рекомендую изучить статью «Domain-Driven Design: создание домена» с примерами, которые более наглядно покажут то, что хотел сказать автор статьи. В свое время, очень сильно помогла всем прийти к DDD без боли.
Как всегда, дьявол кроется в деталях. Разделить код по папкам и завязать их в ядро не самая сложная задача, у вас она поучилась хорошо. Нужно еще не забыть тесты разделить по модулям.
Но вот как потом научить эти модули друг с тругом работать так, чтобы не росла связность?
Я предложил бы уже на старте добавить линтеров на проверку нарушения слоев, пусть это будет https://github.com/deptrac/deptrac или же на уровне psalm можно проверять целостность слоев. Иначе будет каше и беспорядочные связи в модулях
Проблемы с перезагрузкой страницы нет, если у тебя быстрый интернет и ты все файлы статики можешь заново загрузить. Проблема на медленном мобильном интернете, когда чтобы получить основной контент, ты снова ждешь и грузишь шапку, стили и тд.
Для мелких сайтов разницы нет, для больших гигантов это это экономия на запросах к серверу для получения статики и нагрузки на бекенд для генерации меню и прочих динамических вещей на сайте.
Не проще реализовать все через centrifugo. Она написан на go и умеет держать много ws подключений.
А из пхп отправлять события/сообщения через gRPC в centrifugo.
Не думали над таким решением?
Первая самая фатальная ошибка - начать писать на Joomla в 2к22 году.
Обожаю такие статьи, заголовок "... в 500 строк", но по содержанию понимаешь, что чтобы написать эти 500 строк, нужно изучить матан, теорию вероятности, 3Д моделирование и еще кучу всего. Мое уважение автору за старания и отдельный лайк за демонстрацию результата в 3Д!
Звучит логичино и аргументы понятные, но переписать все на %подставь_свтой_язык% для бизнеса означает потерять кучу времени и не факт, что это окупится, а выгоды мало для бизнеса.
И сейчас все гиганты, которые начинали с PHP (ВКонтатке, facebook, badoo и тд), полностью не переезжают на другие языки, хотя денег найти на рынке Go-шника и обучить у них точно хватает. Они перевозят лишь частями свои сервисы, разгружая узкие места. Именно поэтому все чаще встречаются вакансии PHP+Go, чтобы умел и админку на PHP сделать и API под высокие нагрузки на GO накидать.
В этом и минус решения, что все остальные в группе видят этот текст, не круто.
Но основная проблема, что другие участники чата тоже все видят и им уведомления зря приходят. Вот бы как в Slack (там возможно писать сообщения от бота только для конкретного пользователя), бот пишет сообщения, которые видишь только ты.
Судя по документации, у telegram есть возможность отслеживать новых участников в группе (описание объекта Update) и там есть поле
message.new_chat_members[].is_bot. Почему нельзя по этому параметру отметать ботов?P.S. у нас в ulskPHP в телеграм есть бот Ильич, который публикует новости о PHP и шутки в канал, умеет здороваться и откликаться на сообщения пользователей. Именно по параметру
is_botя настроил ответ бота, чтобы он не отвечал на самого себя и других ботов.и
В array_walk идет первый массив, а затем функция, а в array_map наоборот.
А вообще, было бы здоров не только статику делать по типу:
Было бы круто делать так:
P.S. Если уже ломать обратную совместимость, я бы еще иммутабельность завёз.
В магистратуре УлГТУ есть и более IT-шные специальности:
Пруф: www.ulstu.ru/main/view/article/15671