• Как сделать localhost безопасным?

    Lillipup
    @Lillipup
    Allons-y, Алонсо!
    Используй docker
    Ответ написан
    Комментировать
  • Стоит ли стажироваться на php разработчика, если у них cms Битрикс?

    php666
    @php666
    PHP-макака
    лишь только потому, что на рынке его спрос неплохой
    спрос потому, что никто не хочет идти работать с этим ужасом.

    Стоит ли стажироваться на php разработчика, если у них cms Битрикс?
    нет, нет и еще раз нет.

    Можно ли дома самому настолько разобраться во всем, чтобы был полезным на рынке?
    да
    Ответ написан
    7 комментариев
  • Попинайте. Работодатель сказал, что у меня код PHP устаревший. В чем именно проблемы?

    Stalker_RED
    @Stalker_RED
    @mysql_query() уже одного этого кусочка хватает для того, чтобы сильно усомниться в скиллах.

    Функция mysql_query устарела более семи лет назад, и в современных версиях языка ее вообще нет.
    Подавление ошибок через @ - вообще шедевр. У вас, значит, запрос с ошибкой, или база упала - но ваш код это просто игнорирует и делает вид, что так и надо. Зашибись :)

    Читайте https://phptherightway.com/
    Ответ написан
    Комментировать
  • Почему Service Locator это зло и что использовать вместо?

    FanatPHP
    @FanatPHP
    Чебуратор тега РНР
    Все эти страшные слова - они на самом деле всегда про одно и то же - про связность. Когда ты хардкодишь внутри класса вызов какого-то конкретного сервиса - ты намертво к нему привязываешься. И чтобы поменять сервис на другой, ты будешь вынужден поменять код класса. Окей, поменял. И тут же в другом месте, где этот же класс использовался, что-то сломалось! И что теперь? Делать два класса, которые различаются одной строчкой? Нет конечно. А как тогда использовать один и тот же класс для обработки разных входящих данных (или одних и тех же данных, но разными способами)? Сделать его поведение изменяемым. То есть сделать изменяемыми те инструменты, которыми он пользуется - т.е. его зависимости.

    Поэтому все зависимости обычно передаются через конструктор (и поэтому и называются инъекция зависимостей.)

    Таким образом мы можем менять поведение класса, не меняя его код

    Но тут надо понимать, что всё это работает только при правильном применении ООП. А точнее просто при применении ООП. Потому что 98% "ООП" кода, который пишется на РНР - это голимая процедурщина, даже если она обёрнута в классы и методы. Если у тебя метод класса представляет из себя стену кода, которую ты тупо перенёс из файла, инклюдившегося в любимое похапешное спагетти - то это не ООП. Это та же процедурщина, вид сбоку. И смысл использования dependency injection ты с ним не почуствуешь. Будешь конечно применять, но в качестве карго культа - потому что тебе это на тостере написали.
    А вот когда твой код начнет становиться действительно объектным - тогда стразу станет понятнее.


    Похожим на сервис локатор является сервис- или DI-контейнер. Используемый вручную, он является тем же самым сервис локатором. Поэтому вручную его никогда не надо вызывать - что и запрещается в симфоневских конроллерах - а только для автоматического создания классов. В МВЦ у тебя ведь очень многие объекты создаются автоматом - сущности, контроллеры. И вот для того, чтобы при автоматическом создании экземпляра класса у тебя были на руках все требуемые сервисы - и нужен контейнер.

    Соотвтственно, ответ на вопрос "что использовать?" очень простой:
    - при ручном создании экземпляра объекта, все зависимости передавать в него через конструктор, а не получать "из воздуха" в коде.
    - при автоматическом создании экземпляра объекта, использовать dependency injection container

    В этим смысле очень полезно освоить Симфони - строгий фрейворк, в котором нет сервис локатора и в котором запрещено пользоваться контейнером напрямую.
    Ответ написан
    4 комментария
  • Что может линукс, чего не может Mac?

    @Janus_Bora
    Коротко о главном:
    • Плюсы OS GNU/Linux:
      Можно настроить всё, что захочется.
    • Плюсы macOS:
      Не нужно ни чего настраивать.
    Ответ написан
    2 комментария
  • Как правильно настраивать дев-окружение для веб-разработки?

    @xfg
    Не думайте о доменах. Вы смешали администрирование и программирование. Не нужно никакого dev сервера. Делайте работу на локальной dev машине, отправляйте изменения в удаленный репозиторий и всё. Можете вообще не устанавливать nginx/apache и т.д. на локальную dev машину, чтобы не забивать голову всякими доменами, а проект запускать под встроенным PHP сервером например из корня проекта и тогда будете обращаться к вашим сервисам по адресу localhost:port/service1/index.php, localhost:port/service2/index.php и т.д.

    Домены будете создавать уже на продакшене. В простейшем случае склонируете на продакшн машину удаленный репозиторий проекта и в конфигах nginx нужно будет написать что-то типа такого

    server {
      server_name company.com;
      root /home/www/company/frontend;
     ...
    }
    server {
      server_name admin.company.com;
      root /home/www/company/backend;
     ...
    }
    server {
      server_name service1.company.com;
      root /home/www/company/service1;
     ...
    }
    server {
      server_name service2.company.com;
      root /home/www/company/service2;
     ...
    }


    Есть еще мнение, что каждый разраб должен разворачивать себе локальное окружение на своем компе, но хз...

    Так и делают. Разработчикам не нужен никакой dev сервер. Они клонируют репозиторий, делают что-то локально у себя и отправляют изменения в удаленный репозиторий. Для тестеров и всяких менеджеров просто поднимают так называемый stage-сервер где они и тестируют приложение, но это тоже самое что и продакшн сервер, просто доступ к нему только внутри компании. Можно настроить continuous integration чтобы все изменения из репозитория в master ветке автоматически бы приводили к деплою приложения на stage и продакшн сервера. Примерно так в общих словах устроена веб разработка.
    Ответ написан
    22 комментария
  • Как обойти блокировку провайдера "Ростелеком" для https-сайтов внесенных в реестр запрещенных сайтов?

    HawK3D
    @HawK3D Автор вопроса
    Все оказывается очень просто. Как и в случае с http, DPI провайдера перехватывает запросы абонентов и отправляются поддельные ответы от сервера. В случае https нельзя подменить защищенное содержимое, поэтому отправляется поддельный пакет с флагом RST. Запретив такие пакеты - получаем настоящие ответы от сервера:

    /ip firewall filter
    add action=drop chain=forward disabled=no in-interface=pppoe protocol=tcp src-port=443 tcp-flags=rst packet-size=40 ttl=equal:120

    P.S. Под это правило попадает много пакетов, при этом каких-либо проблем обнаружено не было, но для более точной обработки можно поставить дополнительные условия, в моем случае packet-size=40 и ttl=equal:120 (для windows-систем) и ttl=equal:56 (соответственно для *nix-систем) и теперь счетчик правила увеличивается только при обращении к запрещенным https-сайтам. Правило со значением ttl=56 иногда отрабатывает без необходимости, при этом каких-либо проблем замечено не было. Значения ttl смотрел в поддельных пакетах от провайдера и уменьшал их на 1 в правилах.
    Ответ написан
    4 комментария
  • Как писать тесты?

    nonlux
    @nonlux
    Ну тесты бываю разными: и зелеными и красными. ))

    Все зависит от уровня абстракции, который хочется протестировать. Поэтому тесты и делятся на всяческие классификации. Например: юнит (модульные) тесты, интеграционные тесты и т.д. и т.п.

    Я как ярый сторонник BDD использую два типа тестов feature (читай интеграционные тесты) и spec (читай юнит тесты)

    Итак, features. Берем Behat и херачем кучу тестов по типу:
    Зашел на главную,
    Потыкал чего-то в форме регистрации
    Зашел в профиль и увидел свое имя и фотку на странице
    Profit!

    Вот в целом и получили: "Непосредственно регистрация с занесением в БД", только в этой ситуации нам абсолютно не важно что там в БД. Нам важно чтобы пользователь зарегистрировался и попал в закрытый раздел сайта.

    Для таких тестов хорошо иметь поддержку окружения (prodaction, development, test) в коде, чтобы например можно было капчу отключить или еще какую сложную лабуду не делать.
    Если система замудрена до ужаса придется здесь для тестов все окружение поднимать. А лучще вообще отдать CI такое делать пусть друг трудится.
    Плюс таких тестов например когда пишем сложный фронт - сложный бек и еще более сложнейший бек-бек, то можно одним чохом протестировать работу всего сервиса.

    Следующий уровень абстракции spec:

    Если нам в интеграционных тестах было немного пофиг на БД. Она как бы пишет, но что так за структура абсолютно пофиг. То в случае со спекими нам ВАЩЕ ПОФИГ.
    Мы берем наш класс (функцию) и проверяем что за результаты она отдает. Вместо объектов, с которыми подопытный (объект тестируемого класса), даем ему резиновую бабу (моки и т.п), и смотрим на результаты нашего труда.

    Главное при том и другом подходе нам без разницы, что у нас в кишках мы всегда тестируем публичные свойства системы. В первом случае это реакция на пользователя, во втором публичное API класса.

    Вот как то так!

    P.S тесты надо бы писать до кода.
    Ответ написан
    2 комментария
  • Есть ли полноценное расширение загрузки фото для Yii2?

    webinar
    @webinar Куратор тега Yii
    Учим yii: https://youtu.be/-WRMlGHLgRg
    Очень много вариантов:
    https://github.com/search?utf8=✓&q=yii2+image

    По ресайзу:
    Штатный метод:
    www.yiiframework.com/doc-2.0/ext-imagine-index.html
    Мне милее:
    https://github.com/yurkinx/yii2-image

    По загрузке:
    demos.krajee.com/widget-details/fileinput - много функций, есть мелкие сложности с валидацией
    https://github.com/2amigos/yii2-file-input-widget - просто, легко кастомизировать

    Вот и видео вдогонку:
    Yii2: загрузка фото
    Ответ написан
    4 комментария
  • Куда копать для знакомства с юнит-тестированием в Yii2?

    Alexufo
    @Alexufo
    противоречивый, сложный, весь компьютерный.
    с англ не дружу.

    Тогда вам в 1С надо. Yii2 на русском только на форуме в виде ответов посетителей.
    Ответ написан
    Комментировать