• Phpunit в Symfony 4, изменить URL сайта?

    voronkovich
    @voronkovich
    Попробуйте так:

    $client = self::createClient();
    
    $client->setServerParameter('HTTP_HOST', 'symfony-test');
    Ответ написан
    3 комментария
  • Какой паттерн проектирования использовать?

    myjcom
    @myjcom
    Депо не создает трамваи. И "команды" исходят от диспетчера.
    Проще обратиться к объектам реального мира.

    можно скомпоновать Прототип для создания Трамваев, Поездов (в php это clone)
    А в Депо поместить - Пул объектов
    Ну а дальше зависит от того, будет ли обратная связь у Трамваев с Депо и с другими Трамваями.

    Примеры тут
    Ответ написан
    1 комментарий
  • Как взаимодействуют микросервисы?

    Losted
    @Losted
    Software Architect
    Обычно - HTTP/REST для синхронных вызовов и разного рода очереди - для асинхронных. Возможно взаимодействие и через интернет, конечно, но чаще это внутряк. С точки зрения деплоймента - это может быть любая комбинация в зависимости от конкретных условий (отдельные железки\виртуалки\контейнеры и отдельные\шаренные БД). При шаренных ресурсах важное условие - изоляция, то есть данные одного сервиса или наличие сервиса на той же железке никогда не подразумевается в другом (например прямой доступ в чужую базу), а всегда запрашиваются через API.
    Ответ написан
    2 комментария
  • Как взаимодействуют микросервисы?

    @Doc44
    Нашел такую статью на хабре - https://habr.com/post/302844/ , да ещё и в докладах говорят что "все проблемы решает" docker.


    Да?
    Смерть микросервисного безумия в 2018 году
    Вам не нужна микросервисная архитектура
    И это только легкий гуглежь.

    Основной плюс микросервисов - горизонтальная масштабируемость.

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

    Более того - их может быть несколько экземпляров одинаковых.
    И вы не будете заранее знать к какому именно экземпляру вы обращаетесь.

    Рассматривайте сервис как отдельное изолированное самодостаточное приложение.
    Как правило со своей личной базой данных (разве что между экземплярами одного и того же сервиса используется одна и та же БД; реже - одна БД на несколько различного вида сервисов).
    Чаще всего взаимодействующее с внешним миром и/или другими сервисами по HTTP/HTTPS.
    Иногда взаимодействие дополняют MQ-сервером.


    да ещё и в докладах говорят что "все проблемы решает" docker.


    Как решает так и создает проблем.

    Про решает - имеют ввиду вот что: Докер позволяет прогарантировать что окружение при разработке и окружение при эксплуатации будет максимально сходным.

    А нередко это большая проблема - когда у разработчика все запускается, но в реальной системе глючит. Из-за какого нибудь ерундового отличия в конфигурации, которое сделано в той же системе но под другой уже имеющийся в системе софт и/или в установленных библиотеках (а другую версию поставить нельзя, так как другой софт требует именно той версии) и пр.
    Докер же позволяет изолировать приложение вместе с настройками, которые под него сделал разработчик.
    Ответ написан
    3 комментария
  • Как настроить автоответ на письмо из почты?

    TTATPuOT
    @TTATPuOT
    https://code.patriotovsky.ru/
    Функция mail(). Но лучше - PHPMailer
    Ответ написан
    Комментировать
  • Почему PHPStrom не видит структуру MySQL?

    xEpozZ
    @xEpozZ
    Веб-разработчик
    нажмите в эти места
    5d90661f714cf581644699.png

    1. Обновите схемы.
    2. Выберите нужную схему.
    -------

    После обновления структуры вашей БД, всегда нажимайте обновить.
    Ответ написан
    Комментировать
  • Почему в Python элементы списков нумеруются начиная с 0?

    DevMan
    @DevMan
    не только в змее, но и во множестве других языков (в том числе и без указателей), нумерация начинается с нуля.
    такое себе правило, следование принципу наименьшей неожиданности.
    Ответ написан
    Комментировать
  • Как сохранять состояние приложения, чтобы не было лага?

    sgjurano
    @sgjurano
    Разработчик
    Используйте fork, дочерний процесс за счёт механизма Copy-on-Write в наследство практически бесплатно получает копию памяти родителя (это если у вас Linux).

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

    Мы таким образом дампим индекс размером в десятки гигабайт практически без влияния на производительность и почти без роста затрат памяти, ровно так же это делает например redis (rdb).
    Ответ написан
    3 комментария
  • Js условие в php коде, как использовать?

    Lynn
    @Lynn
    nginx, js, css
    Читать до просветления phpfaq.ru/newbie/na_tanke#js
    Ответ написан
    Комментировать
  • Как правильно назвать сервис в Symfony для вызова в разных местах?

    skobkin
    @skobkin
    Гентушник, разработчик на PHP и Symfony.
    Что такое "не работает"?
    Ну и вы же сами в примерах выше выключили автовайринг. Например, тут:
    TwoBuilder:
        public: true
        ###
        autowire: false
        ###
        class: App\Builder\BuilderBase
        arguments:
          $file: '%kernel.project_dir%/public/files/two.xml'
          $mapping: '%two.mapping%'

    Я, конечно, могу ошибаться, но подстановка аргументов по именам - это, вроде как, часть автовайринга.

    Благодарю за ответ, но все равно такая же ошибка :С

    Ещё есть мысль, что, скорее всего, ваши сервисы FirstBuilder и TwoBilder (правильно: SecondBilder) конфигурируются правильно (если опустить потенциальную проблему с передачей по именам без автовайринга), а ошибка конфигурации возникает именно с сервисом App\Builder\BuilderBase. Обратите внимание, что я имею в виду не класс, а именно ID сервиса. То есть, по факту у вас есть ручная конфигурация двух "виртуальных", если так выразиться сервисов и одна конфигурация дефолтного представления сервиса, которая создаётся автоматически (т.к. автовайринг и автоконфигурация включены глобально, чего вы не показали в вопросе, кстати).

    Иными словами:
    - Сервис FirstBuilder - валиден и конфигурируется нормально
    - Сервис TwoBuilder - валиден и конфигурируется нормально
    - Сервис App\Builder\BuilderBase - пытается конфигурироваться автоматически, но не может, т.к. для скалярных аргументов, массивов и всего прочего, что не сервис нужны либо биндинги дефолтных значений (см. services._defaults.bind)? Либо явная передача аргументов в написанном вами блоке конфигурации.

    Так что вам, наверное, правильнее будет чтобы не выключать автовайринг глобально сделать один билдер дефолтным с ID сервиса App\Builder\BuilderBase дабы система не пыталась сконфигурировать ещё один сервис под этот класс, а второй билдер уже называть как вам угодно.

    Вывод:
    Читать про нововведения в DI после 3.3 (а лучше и про более поздние), осмыслять, рефакторить конфигурацию.
    Ответ написан
    Комментировать
  • Что делать веб разработчику, если уже всё придумано?

    AgentProvocateur
    @AgentProvocateur
    Правильно заметили, что есть люди-исполнители, а есть люди-генераторы идей. Нужно реально взглянуть на себя и...принять это. Быть профессиональным исполнителем гораздо кошернее, чем быть генератором провальных идей. По статистике, 9 из 10 стартапов провальны...зачем пополнять собой этот список? Если ты - рыба, то многого ли ты добьешься от фрустрации по поводу неумения залезать на дерево?

    Самый верный путь к рабочей идее:
    1. Проработать в какой-либо сфере достаточное количество времени;
    2. Познать её изнутри на собственной шкуре;
    3. Выявить в ней боли/проблемы/недостатки;
    4. Решить их с помощью прикладного навыка (программирования);
    5. Обкатать в собственной работе;
    6. Упаковать решение и реализовать коллегам по сфере;
    ...
    7. PROFIT!

    Далее...даже если завтра в голову залетит рабочая идея, готов ли ты её реализовать? У тебя есть команда, готовая работать минимум полгода-год бесплатно на время создания беты, тестов, обкатки, раскрутки? Она сможет действительно реализовать всё как надо? Если нет команды, имеются ли у тебя средства на зарплатный фонд хотя бы для 5 человек на эти полгода-год? А с учетом налогов и отчислений (+30% к зарплате на руки)? У тебя есть условия для работы этих 5 человек? Есть ли у тебя сумма на маркетинговое исследование твоей идеи (или лучше облажаться на авось)? Есть ли у тебя хотя бы миллион на первичный трафик из директа? Или надеешься донести свой стартап до пользователей путём емэйл-спама?)) Я не указал и доли того, что потребуется для реализации небольшого web-сервиса, даже при наличии действительно рабочей идеи. Может быть, идеи не прут именно потому, что ты просто не готов к их реализации, и неча порожняка гонять?)

    Как выглядит стартап глазами романтичного юноши, начитавшегося глянцевых историй успеха:
    1. Придумать гениальную идею;
    2. Закодить в гараже в одну харю или в паре с дружбаном;
    3. Разместить на сервере и получать от мира благодарности, признание и мешки денег.

    Как выглядит стартап на самом деле:
    1. Пахота минимум 10 лет в одном направлении/сфере;
    2. Наработка профессионализма, идей, контактов, связей, клиентской базы, понимания всех нюансов сферы;
    3. Угон базы, угон клиентов на себя, переманивание лучших коллег/сотрудников, оформление юрлица, открытие "своего дела" на рабочей идее)))

    К примеру, "икона стиля" стартаперов - Павел Дуров, он идеолог? Нет! Прикол в том, что он именно стырил рабочую идею (также, как тырят клиентскую базу у работодателя), собрал команду, создал для неё условия, привлек корешей-евреев с еврейскими ресурсами, бюджетами и влиятельной питерской крышей, и обеспечил этому всему грамотный проект-менеджмент и маркетинг. Дело в идее? Нет, дело в реализации:)

    А если серьезно, сайт - это просто промо-материал, как билборд, только интерактивный и в интернете. Языки веб-разработки - такие же инструменты, как молоток для изготовления билбордов. Веб-разработчик - нифига не носитель уникальных знаний (который просто обязан повторить успех Цукерберга, иначе не тру), и всего-лишь современный слесарь, изготавливающий технологичные интерактивные промо-материалы. А теперь представь слесаря, который завидует предпринимателям, которые заказывают у него билборды, и вскидывает руки к небу с криком "Доколе??")) Смешно? Смешнее только реплики других слесарей на тему "если нет идей, значит меняй профессию"))

    P.S. Понимаю, что вряд ли отметишь мой ответ решением, ведь тебе хочется подбадриваний вида "Не сдавайся! Ищи и обрящешь! Не опускай руки и всё получится! Вот тебе ссылочки, вот тебе инструкции!", а не режущей глаза суровой реальности. Но в некоторых случаях действительно полезно осознать своё место в пищевой цепочке - антилопа или гепард, слесарь или архитектор, промо-изготовитель или промо-заказчик и т.д. И исходя из этого уже взращивать свои амбиции, комплексы и фрустрации. Повторюсь - в стремлении стать самым крутым слесарем нет ничего постыдного, и даже в финансовом плане может оказаться куда выгоднее и стабильнее других амбициозных вариантов.
    Ответ написан
    4 комментария
  • Плоха ли описанная архитектура, для laravel?

    @gian_tiaga
    На словах модульная архитектура звучит хорошо, но по факту со временем всё сливается в сильно зависимые модули друг от друга, и сложная поддержка. Монолит проще поддерживать. На нескольких проектах пришлось переписывать из за сложности поддержки из модульной в мнолоит.
    Ответ написан
    4 комментария
  • В PHP канонично сначала проверить, потом сделать или попробовать и обработать ошибку?

    FanatPHP
    @FanatPHP
    Чебуратор тега РНР
    Очень хороший вопрос и тема, в которой самое чудовищное количество самых дремучих северий на единицу кода.

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

    Я понимаю, что это звучит богохульством для среднего пользователя похапе, но в реальности программы пишутся совсем по-другому.

    Пример: В обоих приведенных выше случаях мы имеем масло масляное: попытка подменить пхп в выборосе ошибки. Вопрос - зачем? Если файл не найден, то РНР сам прекрасно сообщит нам об ошибке, причем в подробностях, и скажет в чем конкретно заключается проблема. А по строчке "file not found" иди гадай - путь ли кривой или в имени файла опечатка, или вообще пустоту передали.

    Любые проверки надо делать только тогда, когда есть осмысленный сценарий их обработки.

    И обсуждать выше приведенные примеры имеет смысл только если автор вопроса предоставит такой сценарий. тупое error: file not found таким сценарием не является. Так что в общем случае оставляем код в покое и не устраиваем никакого карго культа из перехвата ошибок.

    Если чисто выбирать между двумя действиями (проверка и чтение) и одним (сразу читаем, потом ловим исключение),

    то последнее предпочтительнее, поскльку это атомарная операция, в то время как между проверкой и чтением состояние системы сожет измениться (файл может быть удален).

    Но повторюсь, если нет никакого осмысленного сценария обработки ошибки, то ловить её не надо.
    Ответ написан
    6 комментариев
  • В PHP канонично сначала проверить, потом сделать или попробовать и обработать ошибку?

    sergiks
    @sergiks Куратор тега PHP
    ♬♬
    В таком примере, как вы привели, if() проверяет только условие существования файла или директории. А try-catch обработает бОльшее число ситуаций: если это не файл, а директория, если права не позволяют читать, если устройство гакнулось и не прочиталось.
    пример автора вопроса
    # Вариант 1:
    f getFileContent(filename){
      if (!file_exists(filename)) {error: file not found}
      return file_content(filename)
    }
    
    # Вариант 2:
    f getFileContent(filename){
      try return file_content(filename)
      catch FileNotFoundException {error: file not found}
    }


    По замыслу if отличается тем, что проверяет предусмотренные варианты, а исключения кидаются в непредусмотренных. Все бросаемые исключения надо документировать, чтобы их кто-то где-то, в итоге, поймал.

    Условные операторы только для локальной логики внутри функции. Отлов исключений может иметь многоуровневую иерархию вне функции, класса. Например, случай не файла-а-папки отловится в одном, а случай нечитаемого сломанного устройства – на самом верхнем уровне всего приложения. И по-разному будут обработаны.

    Внешние материалы по теме:
    1. Пост по теме (на англ.)
    2. скорость выполнения с исключениями и без (без быстрее)
    3. Exception patterns, в частности:


    Ответ написан
    6 комментариев
  • На чём писать он лайн билеты?

    ruddy22
    @ruddy22
    Спасение утопающих — дело рук самих утопающих
    тогда откажись
    Ответ написан
    9 комментариев
  • Как определить является ли переменная файлом или строкой?

    index0h
    @index0h
    PHP, Golang. https://github.com/index0h
    Для таких ситуаций DRY - это антипаттерн. Не стоит объединять вместе разные методы только потому, что они похожи. Лучше выделите 2 метода: один для контента, другой для файлов. В вашем случае например Body не может быть строкой "/some/path" потому, что это вполне валидный путь к файлу, пусть файла и не существует.
    Ответ написан
    3 комментария
  • Как протестировать АПИ на Swager Json?

    Alex_Wells
    @Alex_Wells
    PHP/Kotlin
    Сделать ресурсы под все что нужно, в них кастить к нужному типу, на выдаче использовать только их.

    Тестами можно покрыть только их, если сильно лень покрывать все интеграционными.
    Ответ написан
    Комментировать
  • Composer почему не видит namespace?

    PSR-4
    "psr-4": {
        "App\\": "src/"
    }

    И имена файлов классов с заглавной буквы (Chat.php, Server.php)
    Ответ написан
    1 комментарий