Не разработчик, но посмотреть могу

Достижения

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

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

Все теги (22)

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

Все ответы (23)
  • Стоит ли связываться с Docker?

    ppokrovsky
    @ppokrovsky
    Разверните стенд, попробуйте. Пока не пощупаете руками - не поймете.
    Ответ написан
    Комментировать
  • Почему на production не рекомендуют использовать систему контроля версий?

    ppokrovsky
    @ppokrovsky
    Нет такого, что рекомендуют или не рекомендуют. Все зависит от вашего проекта. Те доводы, которые здесь перечислены насчет CI итд - правильные. Дополнительным аргументом в пользу deploy-скриптов может быть, например, необходимость изменения схемы БД на проде с очередным апдейтом, чего git не сделает сам по себе. Плюс, обновление через git - не очень рабочий вариант в случае компилируемого кода. Конечно, можно навернуть поверх гита каких-нибудь билдеров, но этому уже точно на проде не место.

    Но если, например, проект простой, компилируемого кода нет, и в команде есть договоренность о том, что в master попадает только протестированный код, то никакого криминала в том, чтобы сделать git pull, нет.
    Ответ написан
    Комментировать
  • Как работает MVC controller?

    ppokrovsky
    @ppokrovsky
    Ответственность контроллера в MVC:
    1. Получение параметров из представления (GET/POST итд) и передача их в модель
    2. Возврат представления с параметрами, полученными из модели
    3. Валидация и фильтрация параметров в обе стороны
    4. Контроль доступа на основании правил, заложенных в модели

    То есть контроллер - это посредник между представлением и моделью. Контроллер по возможности не должен содержать бизнес-логику. Представление по возможности не должно вызывать методы модели напрямую, модель gо возможности не должна содержать примеси представления (HTML) и возвращать представление. "По возможности" - так как не всегда это возможно/оправдано с точки зрения трудозатрат разработки.

    Общее правило: тонкий контроллер и толстая модель.

    . Вопрос такой - контроллер создается для каждого запроса отдельно или один запрашивающий получает тот же самый контроллер, что и другой запрашивающий?


    Специфика веб-приложений в том, что на каждый запрос клиента создается новый экземпляр приложения, так как HTTP(S) - протокол без сохранения состояния (stateless).
    Для всех клиентов существует один общий класс контроллера (class myController), но на каждый запрос каждый клиент получает собственный экземпляр контроллера (new myController)

    если один пользователь запросит экшен1, а второй пользователь после этого запросит экшен2 - не может ли он получить значение "9"?


    нет, второй пользователь получит 5, так как взаимодействует с собственным экземпляром контроллера.
    Ответ написан
    2 комментария
  • Как грамотно и безопасно использовать сессии в связке с cookies?

    ppokrovsky
    @ppokrovsky
    Не нужно распыляться на полутора человек пользователей с дисковыми телефонами или текстовыми браузерами. В одной крупной интернет-компании действует общее правило, что браузеры с < 1% суточной аудитории не поддерживаются. В абсолютных числах это тысячи посетителей в сутки - от них сознательно отказываются чтобы сфокусироваться на массовой аудитории. ID сессий в коде или урле это очень-очень плохо, так как кроме явно костыльного решения, это чревато попаданием сессий например в поисковый индекс со всеми вытекающими
    Ответ написан
    Комментировать
  • Как правильно сделать сессии и авторизацию на PHP?

    ppokrovsky
    @ppokrovsky
    Оба подхода не очень хорошие, так как смешивают логику аутентификации пользователя с логикой протоколирования событий. Условно у вас есть 3 модели: User, Session и UserLog.
    Связь UserLog и Session опосредованная через User. Такой подход позволит вам а) организовать хранение сессий в виде "1 пользователь - 1 кука", б) даже если у пользователя умерла кука и ему выдалась новая, вы сохраняете историю пользователя, тк UserLog привязана к User через внешний ключ.
    Ответ написан
    Комментировать