Крайне "забавное" развитие диалога.
Вы оставляете поддерживающий комментарий к статье о том что "нужно быть добрее".
Мне в вашем комментарии "режет глаз" противопоставление "мы" и "они", то как вы по сути уничижительно отзываетесь о моем обществе и окружении ("не доросли до уровня"), списываете со счетов достижения ("только пользуемся") например создателя "nginx", крутых разрабов из например яндекса с их оупенсорс проектами, разработчика php-ng (т.е. core разработчика php7) (имена не привожу их и так все знают, а в контексте мысли не хочу на них заострять внимание) и т. д.
И в ответ на это вы переходите на личности!) В "мы" уже конкретно я и судя по комментарию никто другой. Ищите "подходящий" комментарий. При этом не берете последние (например к этой статье тоже заминусованной сообществом, и тоже у меня комментарии далеко не восторженные, но в них слишком много конструктивных советов наверное и плюсики опять же для скриншота были бы не очень. да?), а находите повкуснее. И в статью вы не вникаете и тот кто будет читать ваш комментарий вряд ли будет читать потом всю ту статью (а еще в идеале и предыдущую от того же автора) и потом еще и все комментарии мои и автора в хронологическом порядке.
Что то вы из крайности в крайность. Их тупыми в IT вряд ли кто то считает. Но вот это "мы не подошли к тому уровню развития", "Мы только пользуемся"… Отличные разработчики есть и у нас (кстати кто в вашем тексте такие "мы" и "они"). И вклад в разработки тоже есть.
Как призыв статья неплоха. Но вот это противопоставление мне кажется надуманным. И возможно так обстоит дело больше в отрасли. Ибо я точно помню очень похожую статью англоязычную. И там правда противопоставлялось именно IT комьюнити с каким то другим (вот что бы не соврать то ли со скейтбордистским то ли со сноудбордистским). Статью к сожалению не нашел. Так же я могу привести точно такие же "спасибо" к русскоязычным статьям, которые на мой взгляд были весьма низкого уровня и качества.
А с чего то, что "бизнес-логика разбросана по всему проекту абы как", это следствие AR? У него другие проблемы. Распухание модели. Не всегда понятно с чем мы работаем в конкретный момент (экземпляр или билдер например). Нарушение принципа единой ответственности. Не ясное положение кода для смежных операций над несколькими моделями. И потому создаются билдеры (хранящие логику создания модели), призенторы, фильтры, трансформеры, "репозитории" (которые обычно для большенства есть хранилице именованных запросов) и т. д. и т. п. И всё это может легко и плавно внедряться с ростом проекта. Главное быть последовательным.
Небольшие — это какие?
Все в кучу свалить?
html / php / sql?
Небольшие это те которые не содержат много бизнес логики и не оперируют множеством моделей. Html вообще может не быть. или запросов в базу может не быть. или модель у меня одна. и т. д. и т. п. Код на уровни разделять это действительно здравый смысл, только MVC это всё же паттерн и при этом не единственный.
То есть фреймворки для ниасиляторов языка, для ниасиливших spl_autoload_register()?
максимально компактный но зависимость от jquery? И как вы сами вообще умудряетесь там всё править в этой мешанине. Ну уже хотя бы как то разделили код метода showFormна части по внутренним темплейтам в heredoc. или вообще зачем там класс тогда, сделали бы просто скрипт, тоже было бы в одном файле но чище. Ну или phar есть.
На самом деле я удивляюсь вашей "смелости". Такое на хабр выкладывать… Идея спорная всё же. А исполнение хуже некуда.
А еще у вас всё плохо с именами переменных. Date где по логике data, safe где должно быть save, Attrebut с одной t. Это я уже не говорю о семантической корректности например имени метода getAtributes
Идея может и неплохая, но код… Приведите код к psr-2. Смените кодировку на utf-8. Добавьте тесты. Замените var на нормальную область видимости. Вынесите шаблон и JS код отдельно от класса.
Эм, из всех ошибок на которые я указал ты увидел только call? Чувак, с тобой точно что то не так. Самая вопиющая ошибка была где ты не понял как вообще работает планировщик в ларе и написал бред
разработчик пишет: When using the scheduler, only a single Cron entry is needed on your server. т.е. нужен только один файл крон нужен, а запускать будем каждую минуту… Это неверное утверждение, если крон-задача очень важна, она может невыполниться ввиду ошибок в другой задаче, поэтому желательно иметь возможность делать несколько файлов крон. ОК, сделаем еще один файл, ...
Ну и тон сообщения это радостно презрительное улюлюкание. "Кландайк!", "антиреклама". Мне тут в одном из комментариев посоветовали уважать ваш труд. Так вот, нет. Вы не уважаете труд тысяч разработчиков.
Я пропущу ваши первые тезисы о неймспейсах, числе файлов, "простоте" вашего кода и необходимости читать документацию. Ибо вам уже дали пару ответов. Скажу лишь что я рад что в Ларе код хранится по PSR-4, что каждому классу отведен свой файл а не свалено всё в единую огромную дурнопахнущую кучу вашего "первого крыла" (как же вы достали со своими самопридуманными терминами) А еще замечу что вы похоже не знаете как работает кеширование кода в php. И что Лара умеет собирать свой код ядра в один файл. Но при этом исходники приятно разложены.
Далее:
крон-задачи простые, например очистка сессий и нужно выполнить один только запрос.
Это не так. То что вы всю свою "карьеру" не писали ничего сложнее блога это ваш юзкейс.
Обычно это отдельная, зачастую ресурсоемкая задача. С достаточно большим временем выполнения. И не тривиальным кодом. (Отправка писем по запланированной рассылке, агрегация данных, подготовка отчетов). В ларавель они красиво вынесены в консольные команды. Но и что то простое можно сделать просто без класса а описав действия в замыкании.
Ваш планировщик — дно неприменимое в продакшене на сколь нибудь серьезном проекте. Я не хочу что бы одни мои задачи зависели от выполнения других.И в ларе представляешь они не зависят. Ибо тот скрипт который прописывается в крон он запускает запланированные задачи прописанные в нем изолированно. Я не хочу писать в crontab новые строки (тем более что доступа у меня может и не быть и делать это надо через админа). А блокировка от двойного запуска долгой задачи? а запуск с особыми условиями среды, часового пояса, ежеминутно но в определенный день или промежуток времени… И еще десяток юзкейсов которые дает Лара и о которых вы в силу вашего скромного опыта даже не задумываетесь. А еще я хочу иметь возможность запустить форсированно (не по крону) какое то задание, например если ночью в момент нужной задачи лег ДЦ, или еще почему то. (Вот для этого в ларе и обернуты они все в классы консольные команды)
if (at('0 23')) lsql(«delete from visitors where dt_l + $s_clear < now()»);
просто в глобальной области видимости, нет никакой опасности переопределить глобальные переменные, у ларавел делается класс, что лишнее
$schedule->command('foo')->weekdays()->hourly()->timezone('America/Chicago')->between('8:00', '17:00');
выглядит сложно и некрасиво.
Ага ну давай повтори это же условие "красиво" в своей системе. Особенно between и timezone. А учитывая что я изучил твой недокод. Сразу отвечу, что ты не повторишь никак.
разработчик пишет: When using the scheduler, only a single Cron entry is needed on your server. т.е. нужен только один файл крон нужен, а запускать будем каждую минуту… Это неверное утверждение, если крон-задача очень важна, она может невыполниться ввиду ошибок в другой задаче, поэтому желательно иметь возможность делать несколько файлов крон.
Это у вас так, а вот в Ларе они запускаются изолированно, представляете до чего программисты додумались. Именно что бы время выполнения или ошибки в одних задачах не влияли на другие. И всё это разруливает 1 скрипт. Вот это да!
Или все-таки Клондайк?
Да кландайк, но не система планировщика Лары, а вот этот ваш комментарий. Он идеально показывает что вы некомпетентный, неуч и к тому же глупы. (Да я "скатился" до грубости, но пора уже огласить правду)
О да, оправдывать не качественный код принципами KISS и YAGNI это круто
Потому что у вас не две строчки кода. Потому что так будет проще тестировать. Потому что так читабельнее. Потому что такой код легче в поддержке.
что бы не сбиваться можно использовать метод
$request->input($key)Выше вы всё же были правы.
спасибо что указали на "соринку в моем глазу"
Крайне "забавное" развитие диалога.
Вы оставляете поддерживающий комментарий к статье о том что "нужно быть добрее".
Мне в вашем комментарии "режет глаз" противопоставление "мы" и "они", то как вы по сути уничижительно отзываетесь о моем обществе и окружении ("не доросли до уровня"), списываете со счетов достижения ("только пользуемся") например создателя "nginx", крутых разрабов из например яндекса с их оупенсорс проектами, разработчика php-ng (т.е. core разработчика php7) (имена не привожу их и так все знают, а в контексте мысли не хочу на них заострять внимание) и т. д.
И в ответ на это вы переходите на личности!) В "мы" уже конкретно я и судя по комментарию никто другой. Ищите "подходящий" комментарий. При этом не берете последние (например к этой статье тоже заминусованной сообществом, и тоже у меня комментарии далеко не восторженные, но в них слишком много конструктивных советов наверное и плюсики опять же для скриншота были бы не очень. да?), а находите повкуснее. И в статью вы не вникаете и тот кто будет читать ваш комментарий вряд ли будет читать потом всю ту статью (а еще в идеале и предыдущую от того же автора) и потом еще и все комментарии мои и автора в хронологическом порядке.
Что то вы из крайности в крайность. Их тупыми в IT вряд ли кто то считает. Но вот это "мы не подошли к тому уровню развития", "Мы только пользуемся"… Отличные разработчики есть и у нас (кстати кто в вашем тексте такие "мы" и "они"). И вклад в разработки тоже есть.
Как призыв статья неплоха. Но вот это противопоставление мне кажется надуманным. И возможно так обстоит дело больше в отрасли. Ибо я точно помню очень похожую статью англоязычную. И там правда противопоставлялось именно IT комьюнити с каким то другим (вот что бы не соврать то ли со скейтбордистским то ли со сноудбордистским). Статью к сожалению не нашел. Так же я могу привести точно такие же "спасибо" к русскоязычным статьям, которые на мой взгляд были весьма низкого уровня и качества.
А с чего то, что "бизнес-логика разбросана по всему проекту абы как", это следствие AR? У него другие проблемы. Распухание модели. Не всегда понятно с чем мы работаем в конкретный момент (экземпляр или билдер например). Нарушение принципа единой ответственности. Не ясное положение кода для смежных операций над несколькими моделями. И потому создаются билдеры (хранящие логику создания модели), призенторы, фильтры, трансформеры, "репозитории" (которые обычно для большенства есть хранилице именованных запросов) и т. д. и т. п. И всё это может легко и плавно внедряться с ростом проекта. Главное быть последовательным.
Небольшие это те которые не содержат много бизнес логики и не оперируют множеством моделей. Html вообще может не быть. или запросов в базу может не быть. или модель у меня одна. и т. д. и т. п. Код на уровни разделять это действительно здравый смысл, только MVC это всё же паттерн и при этом не единственный.
Как вы увидели там такой смысл непонятно.
Всё это было так толсто и неприкрыто), что я не пойму как вы повелись. Или подыграли?)
ну вообще вы не совсем верно выделение сделали) там
т. е. автору.
танцы с preg_match и preg_replace там я так понял из-за комментариев. Другое дело что благодаря коду это не очевидно)
максимально компактный но зависимость от jquery? И как вы сами вообще умудряетесь там всё править в этой мешанине. Ну уже хотя бы как то разделили код метода showFormна части по внутренним темплейтам в heredoc. или вообще зачем там класс тогда, сделали бы просто скрипт, тоже было бы в одном файле но чище. Ну или phar есть.
На самом деле я удивляюсь вашей "смелости". Такое на хабр выкладывать… Идея спорная всё же. А исполнение хуже некуда.
А еще у вас всё плохо с именами переменных. Date где по логике data, safe где должно быть save, Attrebut с одной t. Это я уже не говорю о семантической корректности например имени метода getAtributes
Идея может и неплохая, но код… Приведите код к psr-2. Смените кодировку на utf-8. Добавьте тесты. Замените var на нормальную область видимости. Вынесите шаблон и JS код отдельно от класса.
тут все понимают как оно сделано, кроме вас.
О вы снова на высоте!) Там не используется pthread))
Ну давайте попытайтесь еще.
Эм, из всех ошибок на которые я указал ты увидел только call? Чувак, с тобой точно что то не так. Самая вопиющая ошибка была где ты не понял как вообще работает планировщик в ларе и написал бред
Ну и тон сообщения это радостно презрительное улюлюкание. "Кландайк!", "антиреклама". Мне тут в одном из комментариев посоветовали уважать ваш труд. Так вот, нет. Вы не уважаете труд тысяч разработчиков.
Вы снова ВСЁ неправильно понимаете))
Я пропущу ваши первые тезисы о неймспейсах, числе файлов, "простоте" вашего кода и необходимости читать документацию. Ибо вам уже дали пару ответов. Скажу лишь что я рад что в Ларе код хранится по PSR-4, что каждому классу отведен свой файл а не свалено всё в единую огромную дурнопахнущую кучу вашего "первого крыла" (как же вы достали со своими самопридуманными терминами) А еще замечу что вы похоже не знаете как работает кеширование кода в php. И что Лара умеет собирать свой код ядра в один файл. Но при этом исходники приятно разложены.
Далее:
Это не так. То что вы всю свою "карьеру" не писали ничего сложнее блога это ваш юзкейс.
Обычно это отдельная, зачастую ресурсоемкая задача. С достаточно большим временем выполнения. И не тривиальным кодом. (Отправка писем по запланированной рассылке, агрегация данных, подготовка отчетов). В ларавель они красиво вынесены в консольные команды. Но и что то простое можно сделать просто без класса а описав действия в замыкании.
Ваш планировщик — дно неприменимое в продакшене на сколь нибудь серьезном проекте. Я не хочу что бы одни мои задачи зависели от выполнения других.И в ларе представляешь они не зависят. Ибо тот скрипт который прописывается в крон он запускает запланированные задачи прописанные в нем изолированно. Я не хочу писать в crontab новые строки (тем более что доступа у меня может и не быть и делать это надо через админа). А блокировка от двойного запуска долгой задачи? а запуск с особыми условиями среды, часового пояса, ежеминутно но в определенный день или промежуток времени… И еще десяток юзкейсов которые дает Лара и о которых вы в силу вашего скромного опыта даже не задумываетесь. А еще я хочу иметь возможность запустить форсированно (не по крону) какое то задание, например если ночью в момент нужной задачи лег ДЦ, или еще почему то. (Вот для этого в ларе и обернуты они все в классы консольные команды)
Ага ну давай повтори это же условие "красиво" в своей системе. Особенно between и timezone. А учитывая что я изучил твой недокод. Сразу отвечу, что ты не повторишь никак.
Это у вас так, а вот в Ларе они запускаются изолированно, представляете до чего программисты додумались. Именно что бы время выполнения или ошибки в одних задачах не влияли на другие. И всё это разруливает 1 скрипт. Вот это да!
Да кландайк, но не система планировщика Лары, а вот этот ваш комментарий. Он идеально показывает что вы некомпетентный, неуч и к тому же глупы. (Да я "скатился" до грубости, но пора уже огласить правду)