Задать вопрос
  • Как из контейнера php получить доступ к mysql и выполнять миграции?

    Yuri Kalnin, прописать правильный адрес хоста. Он должен быть таким же, как название контейнера.
  • Можно задать пару вопросов по включению функций чтения свойств файлов?

    andrei2019, это значит у вашего OpenSUSE он через заднее место собран. Ну или попробуйте грохнуть и заново накатить php, вдруг магия сработает (а точнее вдруг билд скрипт просто проверяет libmagic и при его отсутствии просто игнорирует билд finfo, а т.к. его у вас не было, хотя должен быть, то и не поставило).

    В любом случае вы так и не ответили на вопрос, работает ли установка через zypper
  • Как из контейнера php получить доступ к mysql и выполнять миграции?

    Yuri Kalnin, DB_HOST некорректный. Там должен быть "mysql". Название хоста (https://github.com/railt/railt.org/blob/master/.en... должно быть таким же, как и контейнера (https://github.com/railt/railt.org/blob/master/doc... для доступа изнутри контейнера к другому.
  • Не могу сделать вывод из JSON запроса на php?

    в мире больше, чем 3 марки авто, и на мерседесах катается не 90%. но вы дальше продолжаете воспроизводить мантру "мерседес - вот это машина, остальное - говно".


    DevMan, я до сих пор не услышал ответа на вопрос. Что в мире есть актуального и хотя бы на 1/10 такого же популярного как PSR? Пока что вы не привели ни одного примера, лишь хвастаетесь древними поделками, аргументируя это тем, что все привыкли. Это уже демагогия какая-то. Я вот, например, открываю какой-нибудь: getjump.github.io/ru-php-the-right-way/#%D1%80%D1%... и что вижу? PSR, мёртвый PEAR под PHP 5.2 и Zend, который является тем же PSR. Где все эти ваши "огромное количество других"?

    сам шучу - сам смеюсь, номер 2?

    Отнюдь. Мне действительно интересно почему ваша аргументация всегда основывается на том, что если вы возитесь с легаси, то и все остальные тоже должны с ним возиться, мол, по-этому PSR не у всех.

    нет бахвальства, есть целесообразность или ее отсутствие.

    А в чём целесообразность игнорирования общепринятых рекомендаций и возни с легаси? В том, что вам этого не нужно, т.к. код работает и его трогать не надо? Ну тогда не надо приводить его в пример, если этот код никто не трогает. А если трогает, то зачем он такой? Почему вы до сих пор не поправили всё автоматом? Не целесообразно, т.к. у вас нет новых разработчиков, которые приходят, смотрят на код, матерятся и уходят? Ну в таком случае да, ничего исправлять не нужно, т.к. это никому не облегчит жизнь.
  • Как настроить PhpStorm 2016.1.2+Openserver?

    Евгений Иванов, если уж говорить честно, то использовать не профессионально OpenServer вообще, при наличии докера и вагранта)))
  • Не могу сделать вывод из JSON запроса на php?

    ваша аргументация на уровне "мерседес - вот это машина, остальное - говно".


    Если только в мире бы существовало 3 вида автомобилей и на мерседесе катался 9 человек из 10-ти. Остальные 10% просто потому, что жалко выкидывать на свалку свой тазик.

    Попробуйте воспользоваться замечательным правилом бойскаута. Перед тем как закрыть файл - просто сделайте его перед этим чуть лучше. Я работал с кодом, который был написан во времена PHP4/5.0, а сейчас 7.1+ c PSR-12. И повышение качества - не такая уж трудоёмкая задача. Да, не весь код, половина просто была удалена за ненадобностью, но всё же.

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


    Такие конторы называются "веб-студии", которые клепают одноразовые лендинги. Ах, ну да, ещё фриланс. Там не важно кто и как потом будет это поддерживать, главное вывалить клиенту что-то более-менее рабочее. А что у вас за "проекты", собственно такие, где всем срать, простите за прямоту, на то как написан код?

    P.S. Да и во времена, когда кодстайл всего проекта исправляется одной командой в консоли - довольно печально бахвалиться тем, что ваш код игнорирует все возможные рекомендации.
  • Не могу сделать вывод из JSON запроса на php?

    DevMan, множества? Предлагается в качестве альтернативы рассматривать мёртвый PEAR? Или wordpress, который применяется, внезапно, только в WP. Или какой-нибудь битрикс рассматривать в качестве источника вдохновения? Ну это даже не смешно. Всё остальное, либо PSR, либо основывается на PSR, просто добавляются мелочи поверх второго. Что Zend, что Symfony, что Laravel, что Drupal. Любую более-менее актуальную систему бери - везде будет PSR. Стоит уже смириться, что это уже не рекомендации, а стандарт)))

    Или есть аргументация против моих тезисов?)
  • Не могу сделать вывод из JSON запроса на php?

    xmoonlight, если это ваш профильный язык, то однозначно да. А разве нет? Вы считаете, что человек, который не знает основ может считаться тем, на кого действительно можно положиться в разработке ПО? Миддла от ждуна как раз отличает отсутствие необходимости стоять над душой и не поправлять всё за ним. Можно поручить задачу и быть увереным, что она будет выполнена и покрыта тестами, что ревьювить почти ничего не надо будет. Или нет?
  • Не могу сделать вывод из JSON запроса на php?

    элементарно - только со стороны сервера, но не со стороны каждого соискателя) Вы же не скажете каждому всегда писать полные теги, если он привык к коротким? Ещё раз: СО СТОРОНЫ СЕРВЕРА будет проще всего.


    1) Любой не джун и так будет использовать полные теги, т.к. у него есть плачевный опыт и минимальные знания стандартов.
    2) Как уже упоминал DevMan и я - это решается обычным phpcfb или ci, если уж привык и ничего не поделать.
  • Не могу сделать вывод из JSON запроса на php?

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


    Я там дополнил выше ответ. На проектиках в 10 строк кода - это не аргумент, т.к. микросекунды (даже нано, а не микро) никто считать не будет. А на средних проектах под 50 метров (исходников имеется ввиду) - автолоадинг решает на порядки больше, т.к. просто не загружает в память неиспользуемый функционал.


    2. на рендер: регуляркой и шаблонизатором (и сравните).


    Ну да, шаблонизатор будет быстрее, т.к. он кеширует результат в PHP и ничего потом парсить не надо будет. Более того - регулярки довольно медленные и реализация лексическогго анализа поверх, например, lexertl, вместо встроенного pcre будет в несколько раз быстрее:
    spoiler

    Где:
    1) Stateful - предварительная компиляция PCRE + preg_replace_callback
    2) Stateless - тот же самый алгоритм, но без промежуточного кеширования.
    3) Hoa - реализация на основе чистых preg_replace/preg_match
    4) Parle - реализация поверх lexertl

    tps.png
  • Не могу сделать вывод из JSON запроса на php?

    Могли бы просто оступ (пробельный символ) учесть и проблема бы решилась.


    xmoonlight, могли. Но в те времена вроде не использовался bison (или yacc, что там сейчас?) для грамматики, а значит синтаксис патчить было сложнее. Хотя я могу ошибаться.
  • Не могу сделать вывод из JSON запроса на php?

    xmoonlight,
    1) Шаблонизаторы никак не влияют на производительность, т.к. в конце концов они тоже собираются в обычный php
    2) Объекты быстрее (но массивы чуть быстрее инициализируются) и легче всего прочего, они лучше (эффективнее) работают с GC. Помимо этого они позволяют реализовывать автолоадинг, что нивелирует очевидное повышенное потребление памяти при жадной загрузке.
    3) А регулярки зачем? Эти проблемы обычный phpcfb решают, ну или какие-нибудь CI, вроде styleci.
  • Не могу сделать вывод из JSON запроса на php?

    xmoonlight, там ещё что-то было, связанное с XHTML 1.1. До появления HTML5 - это был самый популярный вариант. Ну и SVG конечно же.

    А так да, убрали именно потому, что он конфликтует с другими форматами. И не только его убрали, можно было писать ещё "<% ... %>" и "<script type="application/php"> ... </script>".
  • Не могу сделать вывод из JSON запроса на php?

    Не понял... Зачем для XML делать расширение PHP?!


    Это правда. Не нужно, если есть нормальный роутинг, то проще написать более адекватный вариант, вроде:
    $router->get('/sitemap.xml', 'Controller@action');

    Но бывают случаи же и другие.

    В любом случае у вас тут не просто так echo вперемешку с нормальным выводом. Предлагаю чуть отрефакторить и разделить логику и представление.

    Возьмём обычный twig (соли, перца по вкусу).

    <?xml version="1.0" encoding="UTF-8" ?>
    <urlset>
     <url>
      <loc>http://{{ site.name }}/goods/</loc>
      <lastmod>{{ site.modified | rfc3339}}</lastmod>
      <priority>1</priority>
     </url>
    ..............
    </urlset>


    // ...
    public function render(): string
    {
        return $this->twig->render(..., ['site' => $this->site]);
    }
    
    
    // Вывод
    \header('Content-type: text/xml');
    
    $site = new Site('Name', new \DateTime());
    
    echo (new Sitemap($site, ...))->render();


    Теперь код стал чище, он стал тестируемым за счёт композиции объектов. А если заменить Site на интерфейс, то получится реализация инверсии контроля, т.е. можно будет добавить реализацию чтения настроек, например из БД. Всё круто, но код, внезапно, просто не будет работать там, где нарушена рекомендация в отключении шорттегов.

    В любом случае вам очевидно, где проблемы шорттегов, иначе бы не костылили заголовок с помощью echo.
  • Не могу сделать вывод из JSON запроса на php?

    Хотелось бы про них узнать, т.к. сам я на практике ни разу не столкнулся...


    Ну попробуйте создать простой XML файл с расширением php и подставить туда переменные.

    Я пишу код в notepad++ и пользуюсь несколькими плагинами. Надо выложить код в репу - я пройдусь плагином Indent By Fold. Мне пока хватает такого простого IDE с головой и не вызывает затруднений или неудобств при разработке. Пока не вижу для себя смысла переходить на более "тяжёлые" IDE.


    Ну хватает, значит хватает. Значит вы настолько опытный, что сходу можете найти проблему в простом и даже рабочем примере:
    function starts_with(string $haystack, string $needle): bool
    {
        return $needle !== '' && \substr($haystack, 0, \strlen($needle)) === $needle;
    }


    А если использовать IDE, то она очевидна
    fzu13fhyrdpudy9_vrbtshtgr7a.png


    Лично я не могу держать в памяти весь код, что он возвращает, какие исключения кидает и прочее.
  • Не могу сделать вывод из JSON запроса на php?

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


    Не только. Ещё трудозатраты. Некоторый функционал и исправления не был принят (т.е. был отложен) просто потому, что очень много чего переписывать надо. Именно по-этому так форсится работа Стогова. Он взял и пофиксил один из таких "проблематичных" моментов, который очень сложно было исправить и реализовал функционал для будущих плюшек. Все обновления, начиная с 7.0+ - это лишь рефакторинг ядра и ничего больше, который позволил бы в будущем реализовать огромную кучу функционала и исправить старый.
  • Не могу сделать вывод из JSON запроса на php?

    xmoonlight,
    Код в первую очередь должен работать/исполняться быстро, безопасно и как требует бизнес-логика проекта/сервиса.


    Требование "просто работает" применимо только к прототипам и одноразовым скриптикам. Такие характеристики, как:
    1) Читаемость
    2) Поддерживаем
    3) Правильно скомпанован (я хз как сформулировать тезисы об инкапсуляции побочных эффектов и SOLID в целом), что повышает тестируемость и расширяемость.

    Имеют первостепенную важность, если код является частью единой системы. В этом случае баги и недоработки фиксятся за пару минут, а новая задача, поверх старой не потребует лишних телодвижений. Я вообще не припомню случаев, где требовалось бы сделать N по тех.заданию и забить. Каждый проект, если он живёт, то постепенно дорабатывается, улучшается, а бизнес-логика меняется. Задача программиста - это найти границу между минимальной стоимостью разработки и поддержки. А в некоторых случаях (например, в Open Source) задача стоит только одна - максимальное качество кода.

    А как он будет восприниматься - зависит уже от конкретного специалиста.


    Согласен. Но делать его в стиле барокко и говнокодить, оправдываясь этим - не стоит.

    Для тех кто только начал кодить и особо ещё не научился - важны понты в виде соблюдения PSR.


    Да что уж там, давайте тогда и на отступы забъём. Кому нужны переносы строк и пробельчики? Это же просто понты!

    Не, я согласен, что резон в этих словах есть. Для начинающих не важно на какой строке стоит фигурная скобка, но минимальные правила (только UTF-8 без BOM, опускание закрывающего `?>` и проч.) должны выполняться всегда. Это не прихоть, это решение огромного вороха проблем. Да даже далеко ходить не стоит: Почему пишет, что хедер уже послан? Этого бы не было, если бы человек удосужился выполнять простые правила PSR.
  • Не могу сделать вывод из JSON запроса на php?

    DevMan, ну хз, я пока не встречал того места, где было что-то отличное от PSR (естественно, уже после того, как он появился).

    не знаю или вы помните сколько было воплей, когда в пыхе сделали short_open_tag по дефолту выключенными


    Хм, я не помню этой истории. В целом, ваше рассуждение вполне логичное, что лучше перебздеть, нежели... С другой стороны шорттеги попортили крови довольно много кому, я до сих пор с содроганием впоминаю как дебажил самопальный sitemap и пытался понять откуда ошибки. Короче, шорретг "<?" правильно запретили, это логично, т.к. ведёт к куче проблем. А "<?=" не запретят в ближайшем будущем или вообще никогда, т.к. проблем связанных с ним не было и никому оно не мешает.

    Т.е. я к тому, что из пыха убивают только проблемные конструкции, регистер глобалс, шорртеги, декларация через script и asp-like и проч. Но беспокоиться за "<?=" не имеет смысла, т.к. она не взодит в группу "ненужного функционала".
  • Не могу сделать вывод из JSON запроса на php?

    DevMan,
    1. Вы забыли про то, что это "общепринятые рекомендации", так что учитывая это можно сказать, что это уже стандарт. Код не по PSR в 2018ом году воспринимается как дилетантский, разве нет?
    2. И это разве плохо? "<?=" работает на любой конфигурации сервера, на неё не влияет наличие или отсутствие каких-либо флагов.