Никто не заставляет вас его использовать, но как минимум объявлять переменную лишь для того, чтобы ее использовать в последующем условии — звучит бредово, при условии что метод возвращает булевый результат:
$result = someMethod($args)
if ($result) {
// do something
}
// а почему не вот так?
if (someMethod($args)) {
// do something
}
// при однородности условия тернарник выглядит вполне себе вменяемо:
$doAnything = (someMethod() ? action1() : action2());
Впереди вас еще ждут «магические» методы __isset(), __get(), __set() и тогда вы еще больше сократите этот «макаронный» код — ваш WebResource превратиться в 8-10 строчек с 3мя методами…
Я это к чему — код выше совершенно не выдерживает критики ни с какой стороны: ни с точки зрения целесообразности такой реализации, ни с точки зрения его качества и принципов проектирования. Не следует воспринимать комментарии как личную критику, вам скорей дают советы «как не нужно делать в 2019» на php.
Не понимаю зачем вы это сделали вообще. Но к комментариям выше относительно кода, PSR и прочего есть вопрос к вот такой конструкции:
class WebResource
{
public $dependency = array();
public function setDependency($dependency)
{
$isArray = is_array($dependency);
if ($isArray) {
$this->dependency = $dependency;
}
return $this;
}
}
даже в php уровня 5.5 и выше она выглядит как то излишне избыточной, зачем вы объявляете переменную сразу как пустой массив (ведь на null куда проще проверять чем на count() пустой массив) и объявляете ее публичной, уже тогда делали вот так:
class WebResource
{
private $dependency;
public function setDependency($dependency)
{
$this->dependency = (is_array($dependency) ? $dependency : null)
return $this;
}
}
ну а в эпоху php 7.x можно запросто делать вот так:
class WebResource
{
private $dependency;
public function setDependency(?array $dependency): self
{
$this->dependency = $dependency;
return $this;
}
}
Похоже вам действительно платят либо за время, либо за количество строк кода. Не делайте так, пожалуйста, такие труды явно не заслуживают публикации в 2019ом на хабре.
Зачем «это» пропустили из песочницы… Я все понимаю, у всех разный уровень знания языка, но это ведь явный пример того, как не следует делать в 2018ом году. Просьба — верните «это» обратно в песочницу.
Посмотрел код библиотеки — написана очень качественно с точки зрения OOP модели, даже тесты есть… Попробовал найти применение конкретно в области планировки задач — и не смог, к сожалению в данный момент это лишь «календарь», который умеет разбирать синтаксис iCelendar. Присоединюсь к hamnsk — в моем понимании CronJobber как любой Task просто обязан иметь возможность контролировать состояние потока.
Более того, я считаю что для библиотеки Cron менеджера просто недопустимы вот такие вещи:
При запуске планировщика при помощи cron я советую сохранять время последнего запуска, и при следующем запуске передавать его в параметр $from прибавив одну секунду, так как точность cron'а не идеальна, и существует вероятность пропустить какие-либо задачи или выполнить их дважды.
Как итог оставлю свое личное мнение — библиотека написана красиво и качественно, но к сожалению едва-ли применима как полноценный CronManager.
Хорошая статистика, но по-моему не хватает самой важной — это соотношение публикаций содержащих код к публикациям без программного кода. Многие наверное заметили, что публикаций на хабре, как-либо рассматривающих программный код стало существенно меньше а их качество — хуже (да и все мы помним разделение на потоки «администрирование», «управление» и т.д.). Разделять публикации на те или другие вполне просто — нужно всего-лишь искать в них вхождение < code />.
А какие проблемы с Selenium? У меня codeception для AcceptanceTests вполне безошибочно работает с selenium'ом и драйвером для chrome, настройка закончилась загрузкой selenium-standalone.jar и chrome-driver.exe.
Docker на win вполне себе работает, возможно с некоторыми проблемами в виртуализации, но по моему мнению для dev-env этого хватает за глаза.
На другой стороне средние и крупные проекты у которых сложность локального стека может зашкаливать.
Так это не проблема венды, это конкретно проблема самого проекта в плохой организации его структуры или неудачном выборе инструментария…
Присоединюсь, абсолютно никаких проблем в веб-разработке на «венде» нет, как и собственно не понятно какие проблемы затрагивает автор в статье (конкретно не приведено ни 1 проблемы, которую автор решил или настроил). Дополню список:
Веб-сервер: никаких проблем, подымайте nginx/apache, готовые бинарники всегда есть на сайтах разработчиков
Базы данных: mysql,pgsql а так же ряд noSql вполне удовлетворительно работают, бинарники опять же есть на сайтах разработчиков
git отлично работает из cmd/powershell, кроме того есть очень удобные GUI для новичков (привет от github for desktop)
Интерпретаторы: php 5/7 TS/NTS, ASP.NET, ruby. Единственное, где я «хапнул горя» был python 3.5.x, где возникли проблемы со сборкой, если верно помню, драйвера для субдб из pip
Проблема с докером действительно существует в win, но она не настолько критична для dev-env
Не обессудьте, но все же несколько «камней» в огород *nix кинуть тоже можно — как часто работаете с версткой? Как там photoshop? Я все понимаю, есть gimp и krita, но не зря большинство дизайнерских разработок в формате .psd…
Поэтому тоже присоединяюсь к вопросу — какую именно техническую проблему решает автор статьи?
P.S. — почему автор выбрал 14.04? Мы живем в разных ветках времени с вами? 16.04 вышла полтора года назад, на носу — 18.04 LTS с gnome.
Простите за зануду, но не нашел подтверждений для "Исходники Apollo 11". Исходники давно опубликовали на гитхабе chrislgarry/Apollo-11. Не в текущем master, ни в инициирующем комите #7 (6e8c67f53145375d48d8a1af8f85384d1b10ec51) не удалось найти ни одного вхождения по «anal», если и используется то вполне корректно как «analysis». Естественно самого комментария в коде нет. Возможно, конечно, он был на стадии разработки проекта, но что-то я в этом сильно сомневаюсь.
Вообще, код — чисто символичный и ничего он там не может вернуть другого, кроме коллекции объектов (см. laravel doc). И да, давно уже никто не проверяет результаты выборок (по крайней мере в разумных orm) на false, null или прочую дрянь, т.к. методы возвращают ожидаемые результаты одного типа (кроме ситуативных, типа ->first() или ->firstOrNull()).
$records = User::all();
foreach ($records as $record) {
// some actions with $record->objects
}
автокомплит, к примеру у phpstorm внутри перебора foreach(){} сует именно records вместо ожидаемой record. Отсюда у меня так же имеется ряд сомнений относительно данной рекомендации (или адекватности автокомплита phpstorm).
Идея, конечно, может быть и имеет смысл (шифровать пароль еще на клиенте) с какой либо солью, но вот качество излагаемого вами кода… Это нечто. Давайте взглянем поближе, самый шедевральный момент:
$db->CheckLogin($_POST['login'],$_POST['password']);
// ...
function CheckLogin($login,$md5pass)
{
$STH=$this->db->query("select password from users where email='$login'");
}
и вы еще беспокоитесь о MITM? Как можно использовать PHP::PDO, но игнорировать preparedStatement? А что будет, если юзер в $_POST['login'] забьет нечто подобное: script.php?login=0'+union+drop+table+users+--+
Ну и далее:
strcmp($md5pass,$pass)==0
почему сравнение используете без типа? Вроде как strcmp может вернуть -1 0 1 и только… Вы ожидаете false и '0'?
А что происходит тут? Зачем вы подключили целую jquery?
window.location.reload() вызывается без всяких там $(document).ready(), это вполне себе стандартная javascript фу-ия еще со времен царя гороха… Да и вообще, если вы уже пишите обработчик на php, то почему не используете header(«Refresh:0»);…
И таких огрехов по коду достаточно. Вам следовало бы подготовится немного получше, перед публикацией подобной статьи, хабр все же не gist.github.com…
В том числе и из-за этой причины данная «фича» не взлетит. Пользователь настолько ленив что едва ли будет заморачиваться проблемами поиска рабочих SOCKS5, а учитывая то, что публичные живут или не долго или работают не быстро, пользователи скорей сменят мессенджер, чем будут заниматься извращениями (для обычного пользователя).
Ага, а потом автор берет и восстанавливает файлы с бэкапа (и не важно как он его называет, PDM/архив/копия/etc по сути это и есть бэкап, формат/местохранения которого просто не занесены в сигнатуры вируса из-за непопулярности данного ПО).
Извините, но такое чувство что автор этого ПО пытается «сорвать покровы» — наличие резервной копии любых данных в удаленном хранилище сводит опасность криптера к минимуму (и это в современном ИТ мире является стандартной практикой, как говорится админы делятся на 2 типа — те, кто делает бэкапы, и те, кто уже делает бэкапы). Кроме того, достаточно сомнительно выставлять преимуществом низкую популярность ПО (целью криптера оно не было и его авторы едва ли знали о существовании вашей системы).
Не знаю насколько отдача заголовка 418 заслуживает описания на целую статью, возможно новичкам будет полезно, но есть одно «но» — данную проблему можно решить еще проще, переключив тип кеширования прям в интерфейсе cloudflare, если конечно не используется «уж очень разный» подход к кешированию (что бывает достаточно редко):
Да, это «узкое» место текеущего роутера, в этом случае не поможет динамический callback, а статические маршруты придется добавлять для всех адресов. Возможно в будущих релизах я пересмотрю роутер в сторону расширения до нужного вам функционала ('/news/*' => '/content/read/news/*')
Роутинг реализован простейшим образом — каждый корневой URI (к примеру, /demo/) будет автоматически адресован контроллеру \Apps\Controller\Front\Demo. Если вас не устраивает такое дело событий — без особых усилий можно назначить как статический алиас, так и динамический каллбэк. Более подробно — тут и тут
С чего вы взяли что это дипломная работа? Это вполне рабочая система, которая уже используется на моих личных проектах и надеюсь заинтересует других людей.
Как вы определяете, что является форматом habrahabr? Или я ошибся с тегами публикации и она ни коем образом не относится к php, cms и ооп?
Я не раз рассматривал такой вариант, в том числе symfony, но мне показалось что для целей CMS у него слишком избыточная система роутинга, а сам фреймворк излишне использует паттерн DI. Нет, конечно я не говорю о том, что это плохо — symfony пожалуй один из самых качественных по уровню близости кода к java фреймворк, но для моих целей он показался слишком тяжелым. На symfony, кстати, есть достаточно неплохая cms — livestreet и в ней как раз таки можно заметить сложности разработки простых расширений, вызванные использованием symfony в качестве основы.
Впереди вас еще ждут «магические» методы __isset(), __get(), __set() и тогда вы еще больше сократите этот «макаронный» код — ваш WebResource превратиться в 8-10 строчек с 3мя методами…
Я это к чему — код выше совершенно не выдерживает критики ни с какой стороны: ни с точки зрения целесообразности такой реализации, ни с точки зрения его качества и принципов проектирования. Не следует воспринимать комментарии как личную критику, вам скорей дают советы «как не нужно делать в 2019» на php.
даже в php уровня 5.5 и выше она выглядит как то излишне избыточной, зачем вы объявляете переменную сразу как пустой массив (ведь на null куда проще проверять чем на count() пустой массив) и объявляете ее публичной, уже тогда делали вот так:
ну а в эпоху php 7.x можно запросто делать вот так:
Похоже вам действительно платят либо за время, либо за количество строк кода. Не делайте так, пожалуйста, такие труды явно не заслуживают публикации в 2019ом на хабре.
Более того, я считаю что для библиотеки Cron менеджера просто недопустимы вот такие вещи:
Как итог оставлю свое личное мнение — библиотека написана красиво и качественно, но к сожалению едва-ли применима как полноценный CronManager.
Docker на win вполне себе работает, возможно с некоторыми проблемами в виртуализации, но по моему мнению для dev-env этого хватает за глаза.
Так это не проблема венды, это конкретно проблема самого проекта в плохой организации его структуры или неудачном выборе инструментария…
Не обессудьте, но все же несколько «камней» в огород *nix кинуть тоже можно — как часто работаете с версткой? Как там photoshop? Я все понимаю, есть gimp и krita, но не зря большинство дизайнерских разработок в формате .psd…
Поэтому тоже присоединяюсь к вопросу — какую именно техническую проблему решает автор статьи?
P.S. — почему автор выбрал 14.04? Мы живем в разных ветках времени с вами? 16.04 вышла полтора года назад, на носу — 18.04 LTS с gnome.
автокомплит, к примеру у phpstorm внутри перебора foreach(){} сует именно records вместо ожидаемой record. Отсюда у меня так же имеется ряд сомнений относительно данной рекомендации (или адекватности автокомплита phpstorm).
и вы еще беспокоитесь о MITM? Как можно использовать PHP::PDO, но игнорировать preparedStatement? А что будет, если юзер в $_POST['login'] забьет нечто подобное:
script.php?login=0'+union+drop+table+users+--+
Ну и далее:
почему сравнение используете без типа? Вроде как strcmp может вернуть -1 0 1 и только… Вы ожидаете false и '0'?
А что происходит тут? Зачем вы подключили целую jquery?
window.location.reload() вызывается без всяких там $(document).ready(), это вполне себе стандартная javascript фу-ия еще со времен царя гороха… Да и вообще, если вы уже пишите обработчик на php, то почему не используете header(«Refresh:0»);…
И таких огрехов по коду достаточно. Вам следовало бы подготовится немного получше, перед публикацией подобной статьи, хабр все же не gist.github.com…
Как вы определяете, что является форматом habrahabr? Или я ошибся с тегами публикации и она ни коем образом не относится к php, cms и ооп?