Контакты
Местоположение
Молдова, Молдова

Достижения

Все достижения (2)

Наибольший вклад в теги

Все теги (41)

Лучшие ответы пользователя

Все ответы (30)
  • GitHub, GitLab или BitBucket?

    Я рекомендую Gitlab
    - Можно хостить весь Gitlab у себя. Вначале это может показаться лишним, но многие работодатели так делают, поэтому навыки по работе с Gitlab пригодятся.
    - Отличный CI. Как по мне, гораздо лучше чем Github actions
    - Проекты в Gitlab можно спокойно и очень просто синхронизировать с тем же самым Github прямо из интерфейса Gitlab, таким образом мы получаем преимущества обеих систем.

    bitbucket всё, забудьте о нём.
    Ответ написан
    7 комментариев
  • Чем занимаются Middle Frontend разработчики?

    Праграмиравает, вот чем он занимается)
    А если серьёзно, то такая градация работников является чистой усвовностью, которая позволяет крупным конторам контролировать ЗП своих работников в зависимости от их скилла. Эта градация хорошо сортируется в их эксель-табличках с перформанс-метриками.
    В разных компаниях миддл может иметь совершенно разные навыки. Миддл в SpaceX и миддл на сайте для продажи женского белья - это два человека с космической бездной между ними в плане профессиональных навыков.

    Т.е. если вы в объявлении пишете, что ищете миддла, то вы сразу обговариваете категорию его зарптаты в вашей компании. И когда вы его наймёте, он не будет сильно сокрушаться, когда узнает, что сеньоры получают больше него.
    Ответ написан
    Комментировать
  • Можно ли уникализировать отправку форм с сайта без cms?

    Ответ выше про скрытое поле абсолютно верен.
    Если же вы по какой-то причине не хотите использовать скрытые поля, то можете просто назначить имя (или value) самой кнопке отправки формы.

    <input type="submit" value="save" name="loginForm">


    if (isset($_POST['loginForm'])){
        // Код
    }
    Ответ написан
    Комментировать
  • Как реогранизовать процесс разработки в IT-продукте?

    1. Git. Без него сейчас ну просто никак.
    2. Gitlab CI или GitHub actions для деплоя.
    3. Пишете скрипт, который при запуске на локалке создаёт новую базу и заполняет её фейковыми данными для тестов. Так новые разработчики не будут иметь доступ к данным.
    3. Новые разработчики будут иметь доступ к коду, смогут создавать свои ветки в Git, пушить эти свои ветки в ваш удаленный репозиторий Git и даже создавать merge request на слияние их ветки с основной веткой разработки. А вы уже сможете сделать ревью их кода и подтвердить слияние, либо отказать. Все права отлично настраиваются как в Gitlab, так и в GitHub.
    4. Если же вы вообще не хотите показывать даже код сторонним разработчикам, то тут без модулей либо даже микросервисов не обойдешься. Я бы начал пробовать с модулей.

    P. S. Если в голову придёт мысль переписать проект полностью, то десять тысяч раз подумайте перед этим. В моей практике нет ни одного успешного переписывания сложного проекта... Всегда нужны новые срочные фичи, и придется параллельно внедрять эти фичи в старую кодовую базу, одновременно с этим пытаться их внедрить в сырую переписываемую кодовую базу. Это может закончиться ещё более запутанным проектом, чем был оригинал.
    Ответ написан
    Комментировать
  • Как создавать, принимать и обрабатывать socket?

    1. Вебсокеты - это сложновато.
    2. Вебсокеты на PHP - вдвойне сложно. Проблема в том, что PHP задуман как скриптовый язык, т.е. скрипт выполняется заканчивает свою работу. А вебсокет - это постоянное соединение, т.е нам надо, чтобы программа постоянно крутилась в фоне. Вебсокеты можно реализовать на PHP, но, как персонально мне кажется, проще будет выучить Go )) , или же, как в ответе уважаемого Артём , сделать сервер на ноде.
    3. Если ваш чат не такой супер-функциональный, как чат в мессенджерах, то вместо вебсокетов можно обойтись SSE (Server Sent Events). SSE так же требует постоянного соединения, но всё работает через HTTP, и это ну прямо намного проще. Единственный недостаток - это то, что SSE работает только в одну сторону: от сервера в браузер. Т.е. запросы из браузера можно получать обычным POST запросом, а отдавать обратно информацию уже через SSE.

    С SSE есть два пути:
    1. Написать сервер самому, используя какую-то простую библиотеку вроде этой https://github.com/hhxsv5/php-sse
    2. Но я бы сделал ещё проще. Есть такой великолепный проект под названием Mercure https://mercure.rocks
    Это отдельный сервис на Go, задача которого как раз поддерживать SSE соединение и отправлять сообщения в браузеры. Сервис сидит в фоне, а браузеры подписываются на события через EventSource буквально в три строчки, как описано тут https://mercure.rocks/docs/getting-started
    Прелесть этого в том, что для того, чтобы отправить сообщение всем браузерам из кода на PHP, вам надо просто сделать обычный POST запрос на специальный адрес этого сервиса Mercure с телом самого сообщения и его id. Т.е. вам не надо делать никаких долгоживущих процессов на PHP, всё будет работать как раньше.

    Т.е. подытожим:
    - Браузеры пользователей подписываются на события в Mercure
    - Пользователь 1 отправляет текстовое сообщение обычным POST запросом на обычный PHP сайт.
    - PHP сайт получает этот POST запрос, определяет, что его надо отправить Пользователю 2, и отправляет соответствующее сообщение обычным POST запросом в сервис Mercure
    - Mercure отправляет сообщение Пользователю 2 через SSE, на которые он подписан.
    - Сообщение появляется у него на страничке
    Ответ написан
    5 комментариев