но тогда зачем рассказывать человеку о maven если можно использовать javac?
и почему именно maven когда я несколько лет сталкивался с java везде повально перезжали на gradle и maven был только там где это исторически сложилось.
Статья ваша вам, видней, по поводу mvn build да был не прав не так написал, имел ввиду именно package.
да package, прошу прощение мое общение с maven окончилось 3 года назад но точно помню что compile на выходу jar и war не давал
а чтобы отработал mvn package необходимо указать entity point
а еще лучше mvn deploy
у вас опечатка прямо «по фрейду»
«По результатам двух-трех месяцев работы будет видно что Фома сделал много а Ерема только отписки и оправдания безделию находит» => «стоимость часа Фомы понизить а стоимость часа Еремы поднять.»
конфигурация с помощью массива, где надо помнить имена ключей или подсматривать документацию.
попробуйте сделать interface
interface ConfigurationInterface
{
public getArray();
}
И сделать классы для конфигурации которые будут реализовывать данный интерфейс и уже иметь методы для изменения.
Ну и везде где аргументом ожидается массив добавить возможность передавать ConfigurationInterface
Мне кажется это бы упростило использование и позволило использовать autocomplete для различных имен.
К сожалению большинство фреймворков конфигурируются различными магическими массивами и приходится заучивать имена ключей.
погрешность при измерение данным способом может быть значительной, по сравнению с profiler.
если устраивает погрешность то хорошо, но я бы выбрал xdebug profiler более точен, существуют готовые инструменты визуализации, субъективно более привычный.
Попробуйте взять одну и туже функцию и замерить ее (несколько раз) с помощью вашего класса и с помощью xdebug и посмотрите на сколько различаются данные между собой и на сколько они отличаются их средние и каков разброс величин.
но тогда зачем рассказывать человеку о maven если можно использовать javac?
и почему именно maven когда я несколько лет сталкивался с java везде повально перезжали на gradle и maven был только там где это исторически сложилось.
Статья ваша вам, видней, по поводу mvn build да был не прав не так написал, имел ввиду именно package.
а чтобы отработал mvn package необходимо указать entity point
а еще лучше mvn deploy
«По результатам двух-трех месяцев работы будет видно что Фома сделал много а Ерема только отписки и оправдания безделию находит» => «стоимость часа Фомы понизить а стоимость часа Еремы поднять.»
Человек изобрел инструмент, ему подсказали что есть вещи и лучше.
конфигурация с помощью массива, где надо помнить имена ключей или подсматривать документацию.
попробуйте сделать interface
И сделать классы для конфигурации которые будут реализовывать данный интерфейс и уже иметь методы для изменения.
Ну и везде где аргументом ожидается массив добавить возможность передавать ConfigurationInterface
Мне кажется это бы упростило использование и позволило использовать autocomplete для различных имен.
К сожалению большинство фреймворков конфигурируются различными магическими массивами и приходится заучивать имена ключей.
но уже довольно давно есть движения в этом направление https://daemon.io/ и http://reactphp.org/
причем у последнего при запуске различных бенчмарков для framework получили преимущества.
Тут не совсем отказ от nginx там скорее отказ от php fpm, но никто не мешает использовать reactphp и nginx вместо php-fpm и nginx.
Да я понимаю что серьезный проект на такое переводить не стоит, но поиграться, вполне можно.
если устраивает погрешность то хорошо, но я бы выбрал xdebug profiler более точен, существуют готовые инструменты визуализации, субъективно более привычный.
Попробуйте взять одну и туже функцию и замерить ее (несколько раз) с помощью вашего класса и с помощью xdebug и посмотрите на сколько различаются данные между собой и на сколько они отличаются их средние и каков разброс величин.
посмотрите в сторону профилировщиков, например xdebug https://xdebug.org/docs/profiler