• Agile или Lean: Ага ага, какая разница-то?
    0
    Тогда это уже не Agile. :)
    Некоторые задачи стоит, чтобы распределял тим-лид, некоторые просто брать из буфера.
    У нас сейчас буфер разбирается по дням по очереди.
    Без тим-лида в команде — это бред. :)
  • PHP: неправильный путь
    0
    При этом я не потратил ни минуты на решение каких-то стандартных задач вроде «отправка почты»

    Я тоже такие вещи не переизобретаю, вроде не раз об этом говорил :)

    Ну и да, у меня еще есть отдельные надстройки которые помогают экономить время. Например валидация данных запросов — https://github.com/fesor/request-objects — я его могу генерить из доки по API.

    Вот и Вы написали свой велосипед. :)
    Так и у меня есть такие надстройки, что мне даже фреймворк не нужен, и все влезает в 50 кБ… :)
    На фреймворках есть плюсы, они гибкие. Но за гибкость нужно платить.
    А также Вы использовали события в своем решении, aktuba был против событий :)
    А также использовали стандартные интерфейсы, а не велосипедные. Вот я и говорю, что не помешало бы иметь такие интерфейсы для меню и хк. Вот увидите, скоро фреймворки это реализуют (а может и уже реализовали, но ни вы, ни я не в курсе :) )
    Хотя не совсем понял, где прописаны у Вас сами правила валидации. Они как-то потом подключаются в зависимости от задач, заметил только проверку чтобы у некоторых запросов не было тела. :)

    Ну и «это скорее CMS» — это вы наверное все же про Yii.

    Хм, Yii никак не CMS.
    Он решает ровно на том же уровне, что и остальные фреймворки.
    Он более монолитный, что имеет свои плюсы и минусы, хотя туда можно тянуть любые компоненты.
  • PHP: неправильный путь
    –1
    Так проблема именно в этом ;). Вместо того, чтобы использовать — переписываете)))

    У Вас есть еда, которая для Вас не вкусная / Вы не любите / плохо желудку?
    Вы ее едите? :)

    Да и я не переписываю, это если бы переписывал, пришлось бы выбросить 90%.
    А так я написал всего 50 кБ. :)
  • PHP: неправильный путь
    0
    вот будет пара миллиардов строк кода — тогда поговорим о фэйсбуках вконтактах.

    Миллиарды строк кода? :)
    Ну да, ну да.
    Судя по этой статье https://habrahabr.ru/post/308974/ Вы погорячились :)

    А также берем во внимание, что там много разработчиков на ставке, а я своим кодом занимаюсь в свободное время как хобби (программирование сначала было моим хобби, а потом уже стало работой).
  • 30 вредных советов для php-разработчиков
    –3
    Меня больше волнует то, что я до сих пор часто прямое использование mysql_* функций…


    Я и на php7 их использую, как абстракцию :)
  • 30 вредных советов для php-разработчиков
    –2
    Это чуть другое.

    Ну и они не индексируются.

    Но как вариант.

    Хотя и раньше можно было сохранять JSON данные.
  • PHP: неправильный путь
    –1
    Видимо, к тому времени, когда проблемой стал язык программирования, объём и сложность уже разработанного кода были настолько велики, что переписывание (читай — «разработка») «с нуля» на другом языке были совершенно невыгоды.


    У меня кода на самописи настолько бла-бла-бла, что переписывать его на фреймворке совершенно невыгодно.
  • PHP: неправильный путь
    0
    здравый смысл мне подсказывает что я лучше поищу готовый вариант нежели буду писать все сам и потом поддерживать это дело.


    Если У Вас остается 90%, то ок.
    А у меня останется 10%. :)
    Проще все выбросить и написать самому 50 кБ.

    И фреймворки это как раз тот готовый вариант для типичных задач.


    Фреймворки не совсем решают типичные задачи. Это скорее CMS.

  • PHPixie против Laravel
    0
    Кстати, использовать
    <?xml version="1.0" encoding="UTF-8"?>
    

    в шаблонах PHP тоже не стоит. :) А вдруг у нас включены короткие теги :)

    И длиннее минимум на 4 символа, так как еще нужен пробел.
  • PHPixie против Laravel
    0
    <? foreach($urls as $url): ?>
    


    можно еще короче
    <?foreach($urls as $url):?>
    
  • SPA — не серебряная пуля, или альтернативный подход к web-разработке. Часть 1
    0
    SPA SPA рознь :)

    Можно примеры SPA сайтов? :)
  • Как «прокачать» навыки программирования… практически без программирования
    +1
    Согласно проведенным исследованиям, люди, которые завтракают, менее подвержены стрессу, более счастливы и обладают лучшей памятью и концентрацией, по сравнению с теми, кто этот прием пищи пропускает.


    Я бы не назвал ту статью исследованием :)
    А еще, все люди, которые умерли, ели огурцы.

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


    Опять сомнительная статья.

    (плюс-минус в зависимости от вашего ритма жизни)


    Ок, +-5 часов :)

    прием стакана воды перед выполнением интеллектуальной деятельности позволяет ускорить работу мозга на 14%


    То есть я буду программы писать на 14% быстрее?
    Цифры из справочника Стеля?
    А если 2 стакана, то на 28%? :)
    Как проводили тестирование?

    Войти в зону концентрации помогает глубокое дыхание.


    Если человек может сконцентрироваться только подышав, или дышет, чтобы сконцентрироваться, то он болен.

    Также вернуться к делам могут помочь и привычки – если во время написания кода вы любите крутить что-то в руках


    Странное написание кода, вертя что-то в руках :)
    Обычно крутят мышку :)

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


    Меломан и без этого совета слушает музыку :)

    правда, настроившись на рабочий лад, лучше переключиться на что-то более спокойное или поработать в тишине


    Как правило, если это музыка из моей коллекции, то мне пофиг на стиль/громкость. :)

    Если вы решили воспользоваться возможностями неизвестного фреймворка, стоит заранее прикинуть, насколько сложно будет его изучить. Задайте себе вопрос, стоит ли результат потраченного времени? Также спросите себя, будет ли легко поддерживать этот код?


    +1. Лучше самопись :)
  • Миф о RAM и O(1)
    +2
    Вообще-то время обращения к памяти при наличии кешей никто и не принимает за O(1). Это вообще несравнимые понятия.

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

    Время обращения к памяти — не строго монотонная функция!

    А также данные и обращения к ним стараются выстроить так, чтобы они шли последовательно. Даже если не будет кеша, мы поимеем выгоду.

    Вообще странная статья, будто автор недавно открыл кеширование. :)

    Кстати, работа допустим с 1МБ данных не гарантирует, что они будут закешированы и доступны за 10 нс.

    Что вообще переводчик думает о статье freetonik?
  • 30 вредных советов для php-разработчиков
    –1
    Подключайте все файлы проекта в любом месте проекта даже если вам нужна всего одна функция.

    Ну вряд ли кто-то вручную подключает все файлы.
    А стоит ли использовать тяжеловесные фреймворки? :)
    Используйте массив GLOBALS — без него вообще никак, разработчики языка придумали его для вашего удобства, а вот проблемы с закончившейся озушкой это проблемы сервера, а не языка.

    Разве GLOBALS страшны закончившейся озушкой. Я такого не слышал :)

    используйте циклы прямо в верстке

    Хм, а как вывести список по другому? :)

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

    Лучше просто использовать метод/ф-ю без наследования.

    Используйте только статические методы и свойства, не нужно создавать объекты, классы придуманы не для этого.

    Когда существует только один инстанс/нету привязки у метода к инстансу, то часто так и делаю :)

    выключите error_reporting — он только мешает

    На проде выключил E_NOTICE
    display_errors само собой

    Храните всю информацию о пользователях в одной таблице — данные для авторизации, анкетные данные, домашние адреса и телефоны, места работы, да вообще любую информацию храните в одной таблице и не забывайте про serialize

    Часто требования на старте одни, а потом другие, или вообще требования не формализированы. :)
    В postgres можно нативно хранить массивы.
    А иногда нужна денормализация. :)
  • PHP: неправильный путь
    0
    Если для вас важна скорость — просто берите Go или Rust.

    У меня не такие большие нагрузки, чтобы оправдано было переписывать.
    Потом, вряд ли у них сейчас более развита инфраструктура, чем в PHP.
    И у них типизация «статическая, строгая».

    «По большому счёту, Go является процедурным языком с поддержкой интерфейсов.»
    (https://ru.wikipedia.org/wiki/Go )
    ООП-шники негодуют :)

    PHP не для этого — он для уменьшения стоимости разработки под WEB.

    Но PHP не настолько медленный, особенно в свете выхода 7 версии.
    Я не совсем понимаю ВК и ФБ, которые с PHP сделали костыли, вместо того, что взять компилируемый язык.

    Си ООП

    То есть на самом деле не так важна явная парадигма языка. :)

    Вот только в отличии от вас у этих «самописей» авторы поопытнее будут.

    Хм, настолько опытные, что решили писать самопись :)
    Если самому не писать код, то можно и остаться программистом на Битриксе (Кодеигнайтер) и уметь только решать задачи в рамках ЦМС/фреймворка. :)

    Потому свои проекты я пилю на ооочень адаптированном под себя symfony. По сути это мой фреймворк который на 90% состоит из отдельных компонентов которые мне лень писать самому.


    На написание кода уходить процентов 10 времени, остальные 90 — это чтение.
    Чем меньше, тем проще читать.
    Фреймворки слишком универсальны.
    Компоненты — это ок.
    Но если мне не нравятся компоненты, которые реализуют ядро фреймворка.
    То, без чего или с другой реализацией чего, по сути это уже другой фреймворк, как Ларавел и Симфони.
    Взять и выбросить 90%? :)
    Если нету цели иметь всеядный комбайн, то можно ограничится созданием ядра только под свои задачи.
    Это ж не так много кода нужно.
    Да и моя самопись эволюционировала с php странички, вся динамика которой была в отдаче элемента массива по индексу из запроса. Самым трудным для меня было понять, как получать GET параметры. Об этом в статьях типа «Создаем сайт на коленке» не говорилось :)

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

    Конечно, затыки бывают не только на бекэнде.

    blablacar например.

    Тоже о них знаю. Это наверно единственный пример.
    У них главная отдается с
    cache-control:max-age=3600, public, s-maxage=3175
    И дурота есть тоже.
    Раскрученный проект не значит умно сделанный. :)
  • PHP: неправильный путь
    0
    4 Я крутой программер, я написал уже несколько больших программ, я знаю все о программировании!!!

    Наоборот :)
    Я стараюсь работать с меньшим количеством кода, так как в голове все это трудно удержать :)
    5. На этой стадии программист переосмысляет само понятия «программирование». Он начинает прислушиваться к другим программистам, обращать внимание на готовые решения, не изобретая велосипед по-новой, на первый план выходят скорость и качества реализации проекта, просматривая чужие листинги, он ищет не ошибки, а интересные идеи.

    Я благодарен критике (наставлениям :) ).
    Если бы все пользовались готовыми решениями и не изобретали велосипед, то до сих пор жили бы в каменном веке.

    Вы считаете себя на какой стадии? :)
  • PHP: неправильный путь
    0
    Каким же образом я отвергаю SOLID и GRASP?

    О GRASP, кстати, впервые слышу :)

    Я за здравый смысл.

    Ну нету мне смысла тянуть фреймворк и все на него переписывать.
  • Основной бизнес Google начал страдать из-за высокой популярности мобильных приложений
    0
    Однако статистика ComScore неутешительна для всех, кто получает доходы от контента, который пользователи просматривают напрямую, минуя мобильные приложения

    Может наоборот, с помощью моб. приложений?

    А данные ComScore, тем временем, показывают, что доля пользователей, которые выходят в сеть через мобильные приложения, продолжает расти.

    Может это из-за того, что там IP сильно динамичный? :) Поэтому насчитывается много уников?

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

    Вот вообще не доганяю смысла сидеть через приложение. Это что, мне на каждый сайт нужно приложение? Бред. Каждый сайт должен создать себе приложение (по сути браузер)? :)

    Доля мобильного трафика доходит до 50% у меня.
  • Agile или Lean: Ага ага, какая разница-то?
    0
    Agile — это бюрократия :)
  • PHP: неправильный путь
    0
    >Перечитайте свою выжимку

    Вы выдумали, что с моим кодом у Вас будут проблемы с наследованием, а с фреймворком не будет.

    Fesor Вы вроде против наследования? :)
  • PHP: неправильный путь
    0
    Коммент пропал. :(

    >вконтактик, фэйсбуки

    Даже Цукенберг признал, что ВК в США работает быстрее ФБ.

    C — тоже без ООП.

    >А по поводу «фреймворков» — юзают в основном на фронтэнде.

    Фронт — это другое государство. :)

    >На бэкэнде у них… ну можно сказать свои фреймворки которые они в опенсурс выкладывают.

    Так все фреймворки проходят стадию самописи.
    Но их авторам тоже говорят: Вась, брось, возьми фреймворк А или Б. У них сообщество, тесты, все такое. :)

    >Да и брать в пример продукты с такими нагрузками в принципе нет никакого смысла.

    Это были козыри. Я проверял, нужно ли такие сайты писать на Симфони. :)

    >А у вас бложик.

    Та бложик это для себя и для лулзов :) Бложик появился совсем недавно.
  • PHP: неправильный путь
    0
    >Снова наговариваете))) Никогда подобного не говорил.

    me:
    >Можно подписаться на событие… :)
    you:
    >Можно. А можно наследоваться и переделать реализацию.
    me:
    >Можно. Но некоторые тру-фреймоворкоюзатели говорят, что наследование — зло.
    you:
    >Т.е. править ядро. Спасибо, не надо)
    me:
    >Это Вы предлагали наследоваться, а не я править ядро…
    you:
    >Верно. Если я наследуюсь и правлю в наследнике — это отлично. Но т.к. у вас header вшит в ядро — это не прокатит, т.к. возможны вызовы в обход моего класса.
    me:
    >Наследование боль. Такая же боль и при использовании фреймворка. :)
    you:
    >Странная у вас логика). Наследование — это удобно в большинстве случаев.

    Вы по ходу переписки выдумываете выдумки.

    >А для апи есть достаточно удобные обертки, например https://github.com/mpratt/Embera

    По описанию это встраивалка видео :)
  • Критерии для оптимального выбора CMS и CMF
    +1
    Собственный фреймворк?

    Тогда ок. :)

    Сам такой. :)
  • PHPixie против Laravel
    +1
    Без short tags, которые deprecated уже

    Где Вы такое вычитали?
    Тут об этому не в курсе:
    http://php.net/manual/en/ini.core.php#ini.short-open-tag
    Как же мы это переживем?
    short_open_tag — няшка :)
  • Что делать с чужими долгами?
    –1
    +1
    Jira неудобная.
    Создавать заявки можно, а дальше головняк.
  • Что делать с чужими долгами?
    0
    Вы молодец! :)

    П.С.
    О менеджерах:
    Иногда приходит такой менеджер без пяти шесть и говорит:
    — Заливай на прод, нету времени объяснять.
    :)
  • PHPixie против Laravel
    +1
    >На мой взгляд любой, даже нормальный, фреймворк — это боль.

    +100500.

    А можете более подробно описать, с какими проблемами Вы столкнулись на фреймворках?
  • Критерии для оптимального выбора CMS и CMF
    0
    >В идеале нужно создавать такие магазины на базе фреймворков и постоянно сопровождать их силами ИТ-специалистов, хоть это и более затратно.

    Так а смысл на фреймворке, если более затратно? :)
    Странный вывод.
  • PHP: неправильный путь
    0
    >Вообще-то, это сказано про IoC

    Видимо текст страницы поменялся, цитату скопировал давно.
    Да и это не суть важно.

    >Наследование — это удобно в большинстве случаев.

    Вы же сами говорили о возможных проблемах наследования… :)

    >Где это я такое предлагал?))) Чёт наговариваете вы на меня)))

    Читайте свои комменты, а то скажете, что имели другое в виду, типа имели в виду, что мой «фреймворк» унылый.

    Остальное лень комментить :)
  • PHP: неправильный путь
    –1
    >А в чем у вас отличие от «фреймворков»?)

    «фреймворк вызывает функции пользовательского кода» (https://ru.wikipedia.org/wiki/Фреймворк )
    У меня более гибридная схема. Чаще я прошу сам, чтобы ядро выполнило какой-то мой код.

    Контроллером/моделью/шаблоном может быть любой сторонний код, хотя пока я использую сам.

    >Простой пример — получить все письма из почтового ящика за последний год по imap. Кода — строк 20-30, а вот ресурсоемкость огромная ;)

    Задача процессор не тратит, это блокирующая операция с сетью.
    Вечный цикл можно и в 3 строки написать. :)

    >Нет, не достаточно. Для 1-5х методов — может быть, а для полноценного использования крупного апи — нет.

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

    >))) Видно, что далекая для вас тема))) Только за счет асинхронности обработки получается сильно снизить нагрузку, не говоря о других плюсах.

    А, ну если вы там видео пережимаете, то да, не стоит заставлять пользователя ожидать, пока браузер загрузится :)
    Но это было давно. Просто сейчас стало модным.

    >Верно. Если я наследуюсь и правлю в наследнике — это отлично. Но т.к. у вас header вшит в ядро — это не прокатит, т.к. возможны вызовы в обход моего класса.

    Наследование боль. Нужно использовать события и грамотно их расставлять.
    Такая же боль и при использовании фреймворка. :)

    >Но всегда, когда их становится много — получается только вред. Как в плане поддержки и развития кода, так и в плане рефакторинга в будущем.

    Их нужно тоже структурировать.
    Если любого кода много, то с ним трудно работать. Поэтому я стараюсь писать меньше кода :)

    >Т.е. для апи стандарта не надо

    Так все апи разные.
    Поэтому проще пользоваться универсальной оберткой.

    >А зачем эта лишняя сущность?) Вы же против лишних сущностей, но я уже с десяток их насчитал ;)

    Так Вы на каждый АПИ сервис предлагаете вводить сущность и реализацию один в один. :)

    >А зачем эта лишняя сущность?

    Модуль ядра — это не лишняя сущность. Это модуль (модель, компонент), который поставляет поставщик ядра.

    >Весь код — нет конечно. Но частично — легко. Например, перевели кеш с файлов на редис — получили доп.функционал в качестве тегов. Почему не использовать? Да, переделываем кеширование.

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

    >Да что вы говорите))). Давно есть реплика в мемкеше?)))

    Репликаций вроде нету.
    Можете сами реплицировать :)

    >А что с ними?)) Думаете, они пишут абсолютно все с нуля?))))

    Я тоже все не пишу.
    Но каркас-то они хоть пишут сами?
    Да и ВК как бы без ООП.
    Или там все на фреймворках у них? :)
  • PHP: неправильный путь
    0
    1) Но все фреймворки имеют указанные недостатки :)
    3) Я и не заставляю всех. :) Если не подходит, значит не подходит. Мне вот фреймворки не подходят. :)
  • PHP: неправильный путь
    0
    Я не о шаблоне меню, а о собирании массива пунктов. :)
  • PHP: неправильный путь
    0
    >Нет. Есть различия. Но суть у них настолько близка, что осилив один — проще понять другие ;)

    Тогда осилив 1 язык, проще другой :)

    >Нет. Ваш вот не дает.

    Но у меня не фреймворк. :) Но подключайте себе через композер.

    >Но самое важное решили скрыть))) Ссылаетесь на вики, а там явно указано, что вы ошибаетесь))))

    Я у себя в статье не оспариваю то, что я якобы скрыл.

    >Абсолютно не понятный шаг. Лишний слой без какой-либо пользы. Проще сразу вызывать нужный контроллер ;)

    Но нам нужно выполнить 10 контроллеров-виджетов.

    >Ну я не виноват, что у вас такая дурная архитектура…

    Архитектура наоборот простая.

    >Вот за всю мою практику — таких случаев не было. Покажете пример?)

    Когда вывод одного контроллера нужно показать в другом, а не использовать костыли в виде виджетов.

    >Как связаны ресурсоемкость запуска и вес кода?)

    Я вообще-то шутя, но разве не чем больше кода нужно перелопатить, не тем больше времени нужно на это потратить?

    >Например, это усложняет разработку, появляется лишний и бестолковый слой.

    Нисколько это не усложняет, наоборот упрощает.

    >Не, вы не поняли. Вот за такой код, как в моем примере, надо морду… ладно, не морду — по рукам бить.

    Я не так выполняю дополнительные контроллеры. Без промежуточных переменных.

    >Т.е. это все-таки другой уровень абстракции. Но вы же настаивали, что не должно быть больше сущностей, чем Model-View-Controller. Снова какая-то двойственность. Раздвоение личности?)

    Я говорил, что модель — это уровень выше, чем контроллер. :)

    >Да не дай бог писать что-то с оглядкой на построителя меню…

    Значит Вам не доводилось иметь динамическое меню.

    >Так по вашей логике тогда именно апи сервисов должны быть в ядре — чтобы было в одном стиле все ;)

    Повторю:
    «я не сторонник мапить апи сервиса один в один. Считаю это псевдопрограммированием. Достаточно удобной обертки над curl.»

    >Кроме вас не знаю ни одного такого, если честно)

    Спросите у сеошников. :)

    >Значит вы очень мало работали с апи)))

    Может и мало.
    Работал с VK и cloudflare.
    Мапинг всех методов 1 в 1 в этих случаях был излишним. Хотите — пишите код, я ленивый программист :)

    >Без понятия. Мне это не важно. Найду что-то удобнее, изучу, начну использовать ;) Вопрос-то не в этом был, а в том, зачем пихать все в ядро, если можно использовать вот так ;)

    Так можно не в ядро. Мне важно наличие стандарта де-факто.

    >А это точно не забота фреймворка. Это забота разработчика и приложения. И да, это нормально, когда несколько раз подключается один и тот-же js-файл например.

    То есть, стреляйте себе в ноги, я не при чем.
    Это не совсем нормально.
    Пример:
    подключили jQuery
    подключили какой-то плагин jQuery
    подключили jQuery

    Вызывается обработчик, который дергает плагин, а плагина и след простыл. :)

    >Ну вы кроме yii вообще ничего «не щупали», как я понял)))). Но делаете выводы про всех)

    Так это ко всем относится. :)
    Или много мейнстримовых фреймворков сделаны в моем стиле?

    >Оооо, как много вам открытий чудных предстоит))))

    Если код не вермишель, а предоставляет АПИ друг другу, то ничего сложного.

    >Ну когда на сервере подключены несколько тысяч посетителей круглосуточно и делают по десятку запросов ежесекундно — и не такая необходимость появляется))

    Если эти микросервисы продолжают жить на одном сервисе, то смысла 0, если это сделано из-за нагрузки. Наоборот, нагрузка увеличится.

    У меня максимум нагрузки — 235к хитов за час. Сервер их не почуствовал :)

    >Ага. Только это про другое было ;). А на вопрос вы что-то не ответили ;)

    Предоставляет единый интерфейс, чтобы не было велосипедов.

    >Т.е. править ядро. Спасибо, не надо)

    Это Вы предлагали наследоваться, а не я править ядро…

    >Правда?!)))) Прямо слеза навернулась… Реализовали проект на событиях, через полгода начали выносить подпроекты в микросервисы — сколько сказочного можно поймать из-за использования событий — не представляете))))

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

    >Потому что вам не понравилось?

    Да. :)

    >Причин там нет в принципе.

    «У меня уже есть отшлифованное легкое ядро всего на 50КБ. :)
    Я хозяин всего кода.
    У меня есть сайты, которые я не хочу переводить на что-либо другое просто ради того, чтобы перевести.
    Я не хочу завязывать свой код на них.
    Я программист, я не кодер.»

    >Если уж понадобится — почему нет?

    Вы ж говорили, что править ядро плохо? У кого раздвоение? :)

    >Еще и реквест разработчикам отпишу.

    А они им подотруться :)

    >Ага, поэтому запихнули в ядро!!! хлебные крошки и меню))))

    Чтобы был единый стандарт.
    Не обязательно в ядро, в модуль ядра.

    >А я против. Под разные задачи мне нужны разные инструменты, делающие одно и то же.

    Наличие стандарта не отменяет права выбора.

    >Например — кеширование. Для мелких проектов мне с головой хватит файлового или мемкеш.

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

    >Для среднего и выше — уже нужно распределенное, более надежное.

    Мемкеш — распределенный.

    >Ох… Жаль вас). Такое говнище…

    Внутри там много старого мусора, который боятся трогать из-за совместимости.
    Но АПИ более-менее норм.

    >Когда задача не для cms.

    Если CMS толковая, то она нечто вроде CMF, так что пофиг.

    >))) Тонко, но мимо. На фреймворках не надо велосипедничать. Они как-раз для обратного)

    Там код писать совсем не нужно? :)

    >После этого получаем проблемы с производительностью, т.к. не запускали optimize table. А если запустили — имеет приложение, которое долго не работает)))

    С 5.7.4 эта операция тоже неблокирующая.

    >Тоже не вижу проблемы связанной с фреймворком. Ну дебил человек — ок, фреймворк-то в чем провинился?)

    Так не фреймворк виноват. :) Просто фреймворк не исправил его. Для этого нужна команда.

    >Т.е. тупо нет опыта работы с такими объемами))). Обработка raw-данных, обычно, делается иначе. Совсем иначе ;)

    Это не raw данные. Это уже агрегированные.

    >Да уже давно нет смысла писать то, что написано.

    А мордокнига и ВК?

    >Я сейчас работаю в проекте, в котором собственный фреймворк.

    Я сторонник самописи, но работаю с фреймворками
    Вы сторонник фреймворков, но работаете с самописью :)

    Жизнь — боль. :)
  • PHP: неправильный путь
    0
    >Ну так вы и велосипедите ;).

    А Вы нет? С тем же меню :)

    >А фреймворки нужны чтобы уменьшать время на разработку, делать разработку удобнее и комфортнее.

    Ну да. Только хотя бы не усложняли. :)
    Это примерно как государство. Оно якобы призвано заботиться о людях, а по факту от него, наверное, больше проблем :)

    >Наличие/отсутствие каких-либо фич не делает фреймворк лучше или хуже.

    То есть все фреймворки одинаковы? Ведь все они дают возможность удобно подключать расширения.

    >Если в вашем фреймворке я не могу использовать одновременно несколько баз данных

    Можете, но построитель запросов расчитан на mysql. Кто хочет, переопределяйте методы :)
    Да и кто использует сразу 100500 баз? А еще говорят о легкости миграции на другую БД.

    Хрен там легко мигрировать, если использованы фишки определенной базы.

    >не могу подключить любую библиотеку с помощью composer — ваш фреймворк ущербен.

    Подключаете композер и все :) Или что может случится? :)

    >И никакие cms-фишки не помогут.

    Ну кому что нужно :)

    >А, т.е. если лишняя сущность «кушать не просит» — она хорошая?)))

    Это даже не обязательно сущность (то есть такого класса может и не быть). Просто пару методов, грубо говоря, наполняющих массив. :)

    >Чем тогда виджеты не угодили — они «кушать непрост» ;)))))

    Они пятое колесо. Но приходится их использовать.

    >Это абсолютно разные вещи, не зависящие друг от друга.

    Ну да, разные, но дублирующие друг друга.

    >К вашему фреймворку так-же можно привязать виджеты

    Их не нужно привязывать, уже есть многоразовые контролеры.

    >виджет никак не связан ни с архитектурой приложения

    Они типа государство в государстве? :)

    >Они для разных целей, абсолютно разный инструмент…

    У меня вышло совместить. :)
    Опишите, для каких таких разных целей они.

    >Зачем вам, при таком подходе, модели и вьюхи? Можно-же в контроллере все делать ;)

    Не-не-не. То что не нужно плодить сущности, не значит, что нужно оставить только одну сущность. :)

    >виджеты/плагины/компоненты/библиотеки — это инструменты.

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

    Для меня важна суть:
    «MVC — модель приложения, пользовательский интерфейс и взаимодействие с пользователем разделены на три отдельных компонента»

    Фреймворки пропагандируют вместо жирных контроллеров жирные модели в одном классе с сущностью и хождением в базу. Модель (бизнес-логика) не должна быть привязана к какой-то одной сущности.

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

    >Более того, вы как-то удобно исключили из цитирования фрагмент чуть ниже:

    Я и так много нацитировал. :)

    >А мы говорим о конкретно вашей реализации, в которой только 1 контроллер и куча виджетов ;)

    Так как в понимании фреймворков не стоит выполнять больше одного контроллера, то с точки зрения фреймворка это выглядит так:
    точка входа / фронт-контроллер (index.php) вызывает т. н. главный контроллер-виджет
    главный контроллер-виджет и его шаблон может вызывать вспомагательные контроллеры-виджеты.

    >Получается, у вас вообще нет контроллеров?!)))

    Почему Вы так хотите лишить меня контроллеров и обмазать виджетами? :)

    >Но это глупость и бред.

    Но часто без этого никак.
    А еще их не хотят использовать из-за того, что их запуск слишком ресурсоемкий. У меня с этим все норм. 50 кБ, как никак :)

    >А в данном примере созданный контроллер используется в виде виджета ;)

    Ну да. То есть виджеты можно легко удалить.

    >Предположим, есть кеш-файл (шаблона, данный — не важно) cache.php. По вашей логике — это модель. Правильно я понял?))))

    Разумнее это рассматривать тем, кешом чего это является. Если некоторый шаблон используется повторно — это не делает его моделью. Если некоторый контроллер-виджет вызывается на нескольких страницах — он не станет от этого моделью. Это уровень выше.

    >Ахахаха… Тогда будет комфорт и удобство. Но по вашей логике — это очень-очень плохо)))))

    Если все сторонние вещи на сайте писались с оглядкой на один и тот же построитель меню — то норм.
    Если же вообще сторонних вещей нет, тогда о какой расширяемости и т.п. мы говорим.

    >А чем это отличается от хлебных крошек?))) Это-же все-лишь методы. «Кушать не просят» ;). Но в случае с хлебными крошками, по вашему мнению, необходимо пихать в ядро фреймворка, а апи сервисов нет. Почему такая двойственность?))))

    Хлебные крошки одни, а сервисов много.
    Хлебные крошки нужны большему количеству поьзователей.
    Не обязательно в ядро. Можно в подключаемый по необходимости модуль ядра (поставщика фреймворка), чтобы не было 100500 конкурирующих стандартов, каждый из которых пытался выступить единым стандартом :)
    Кстати, я не сторонник мапить апи сервиса один в один. Считаю это псевдопрограммированием. Достаточно удобной обертки над curl.

    >И при чем тут линукс?)) Вообще, при чем тут монолит/микроархитектура? Вроде как говорили про конкретную реализацию — ваш фреймворк.

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

    >composer.json -> assets

    Ну ясно, что свято место пусто не бывает :)
    У конкурирующих реализаций интерфейсы совместимы?

    >И фреймворк не содержит лишнего говна.

    Это можно держать в модуле ядра (поставщика фреймворка). Главное, чтобы не было 100500 конкурирующих несовместимых решений и ни одно из них не принято стандартом по умолчанию.

    >И мне не надо ничего реализовывать.

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

    >Для меня phalconphp решает кучу задач — от производительности, до разделения приложения на микросервисы. И это не говоря об удобной работе с любыми базами данных, серверами очередей, серверами сообщений, фоновых обработчиков и пр.

    Не знаю на сколько он удобный, не щупал.
    А в чем трудность разделить приложение на микросервисы?
    И в чем такая необходимость?

    >А что решает ваш фреймворк? Добавляет возможность вставить хлебные крошки и меню?!)))))))))))))))))))

    Вы ж говорили, не в фишках дело :)

    >А можно наследоваться и переделать реализацию. Например, чтобы в апи отдавался 1 заголовок, в веб другой, в cli третий. И каждый вариант содержит свой логгер. И этот вариант будет проще поддерживать и отлаживать, чем вариант с событиями. Не говоря уже о том, что события иногда вообще вредны.

    Можно.
    Но некоторые тру-фреймоворкоюзатели говорят, что наследование — зло. Но оно тоже имеет право на жизнь. Нужно смотреть, как удобнее решить задачу.
    События как бы дают большую гарантию, что вы не разъедетесь с тем, на события кого подписаны. Но да, для них нужно заложить возможность.
    Наследование может привести к тому, что вы разъедетесь с тем, кого наследовали.
    То есть: вам нужно выполнить ровно то же, что и родитель + еще что-то. Кмк для этого нужно вызывать parent::bla_bla_bla(). Но parent::bla_bla_bla() может так измениться, что что-то сломается из-за последующего вызова кода наследника.

    >Вам уже сотня людей сказала, что вы не назвали минусов фреймворков ;). Все, что вы говорите — «я не разобрался — значит это плохо»)))).

    Там дебильное MVC и работа с базой.
    Мне, возможно, более подойдут микрофреймворки. Но переделывать все, ради того, что это было на фреймворке «как у всех» смысла не вижу.
    Ну и другие причины, о которых сказано в статье.

    >Блин, 4-й раз прошу пример, когда реализовать что-то на самописе будет проще, занимать меньше кода, работать быстрее, чем на фреймворке.

    Уже отвечал, но еще раз.
    Как раз 4 примера на каждый запрос :):
    «Отсутствие единого интерфейса для построения массива пунктов меню, хлебных крошек.
    Отсутствие единого интерфейса для возможности отдачи 304 ответа (header($_SERVER['SERVER_PROTOCOL'].' 304 Not Modified'); мы-то послать может. Но нужно знать, что страница действительно не изменилась).
    Отсутствуют языки-фоллбеки для переводов определенного языка.
    Пример: перевода на русский нету, тогда используем переводы в порядке наличия из языков-фоллбеков: украинский, английский.
    У добавленных цсс/жс файлов нету признака, что файл изменился.»

    Остального нету под рукой. Но статья постоянно обновляется, следите за новостями :)

    >Не поверите — с ними никто и не парится)))

    Значит у вас нету сторонних решений.

    >Почему можно в одном месте подправить, а в другом нет?

    Вы правите код фреймворка? Да, его можно в git положить, но у многих git-а нету. Да и вряд ли с композером это прокатит. Сидеть и потом выискивать изменения и накатывать? :)

    >Как-минимум, что-то наподобие redis сильно облегчит разработку, но ваш фреймворк его просто не поддерживает. И использовать стороннюю реализацию в вашем случае накладно.

    Совсем не накладно.
    Сторонние реализации как раз приветствуются.

    >Да, запрашивают.

    А что Вы рекомендуете, может и мне будет интересно и остальным пользователям. Статья будет? :)

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

    Если есть 1, который принят как стандарт де-факто, то я не против.

    >В вашем варианте — надо велосипедничать)

    Подключайте так само и используйте.

    >По работе используем монгу, вес базы под террабайт. Чувствует себя отлично)

    Значит информация устаревшая и пофиксили.

    >Даже если есть что кастомизировать — я буду юзать cms. Будь это wp или modx — кастомизировать их проще, т.к. огромное количество готовых модулей.

    Часто эти модули дают о себе знать значительным падением производителности и они дырявые, но то такое.
    А если нету модуля, который кастомизирует так, как нужно?

    Хотя доводилось работать больше 3-ех лет с Битриксом. Можно использовать. Печально то, что разработчики не прислушиваются к пользователям, а также некоторые кострубатости АПИ.

    Когда по Вашему стоит завязывать с кастомизацией CMS и переходить на фреймворк? Или все же лучше не переходить на фреймворк вообще? Ведь на фреймворке велосипедить нужно больше, чем на CMS.

    >Попробуйте написать адекватную библиотеку для работы с монгой ;).

    Я с ней не работал.
    Там есть SQL-интерфейс?

    >$users = Users::get()->findBy(['username' => 'username'], ['sort' => ['lastLogin' => 'desc']]);

    Сортировка/группировка/джойны на клиенте?

    Но если Вы с ней только из-за того, что у РСУБД проблемы с удалением, то возможно уже таких проблем у mysql 5.6.что-то+ (и форках) нет:
    http://dev.mysql.com/doc/refman/5.7/en/innodb-create-index-overview.html#innodb-online-ddl-summary-grid

    Помечаем элементы удаленными, ночью удаляем, и запускаем ALTER TABLE… ENGINE=INNODB, который якобы стал неблокирующим.
    Ну и можно использовать партиционирование. По непроверенной информации дает ощутимый прирост.

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

    Просто на всех работах на фреймворках был говнокод :)
    Даже хотя бы не то, что не говнокодили, а отступы не прыгали туда-сюда. Исправишь все, а завтра опять придет в репозиторий то самое. :)
    Ну или говоришь такой старшему разработчику, зачем здесь такие костыли, зачем ты лезешь в хату через окно, если можно через двери? А он типа: я спешил, пусть будут.
    А чтобы использовать эти костыли приходится брать еще одни костыли (тем окном пользуется тимлидов код, другим окном мой код залазит в тимлидов, так как на балконе установили окна :) ).
    Ну или говоришь такой на ИС: какой баран (я человек прямой, людей баранами называю не просто так, а за дела, не с целью обидеть, и себя тоже иногда) тут виджет влепил, который делает примерно такое: echo '<table>дальше пошла таблица'.
    А он такой: я, на нашем фреймворке по другому сделать нельзя, это сделано потому что что-то там нельзя разместить выше по коду, и вообще, мне обидно. :) Ну а потом ты досрочно не проходишь ИС.
    Ну или говорит такой тимлид: так, нашим пользователям нужна сортировка объявлений по ctr и в эту статистику должна входить реалтайм статистика, еще не записанная в базу (если выбран текущий день, а он выбран по умолчанию, и это статистика за день, так как пишем только ночью).
    А это влечет за собой выборку всей базы, всего мемкеша и сортировку этого чуда на клиенте.
    Оптимизации, чтобы сортировка была проще, откинули, ибо для этого был необходим аж один дополнительный ключ в мемкеш для объявления. Откинули также более частые сохранение в БД с менее точным ctr. google в то время статистику за текущий день еще не показывал в аналитике. adwords сильно не пользуюсь, разводят на деньги, не знаю, есть ли она там сейчас.
    Ну я и не доделал это, так как в один прекрасный вечер сообщили: Ты не прошел ИС, деньги заплатим позже, ну так их никто и не заплатил. :) Ну и контора потом накрылась :)

    Думаю, это больше от команды зависит. Если самописцы не замкнуты в себе, то все норм.
    Хотя и на самописной доводилось работать. У разных клиентов были несовместимые версии CMS :)
    И если команда-говнокодеров на фреймворке, то хоть им на лбу кол теши.

    >И они пишут на фреймворках, кстати ;)

    Как раз выше написал примеры подтверждающие, что не факт. Может их процент там выше.

    >P.S.: на этом дискуссию закрываем. Выходные закончились)

    Ок, ответите как сможете :)

    Вопрос, который меня больше всего беспокоит:
    В каких-то случаях оправдано использовать самопись? Есть ли людям, использующим самопись, оправдание? :)
  • PHP: неправильный путь
    0
    >Вообще говоря — нет. Хранилищем данных может выступать и кэш, xml файл, внешний сервис, что угодно.

    Ок, не база, а хранилище данных.
    Интересно, какой оверхед у кеша (допустим мемкеш) doctrine по сравнению с чистым PHP.

    О, вспомнил. На моей первой работе с фреймворками (Yii) отказались от моделей фреймворка (DBAL/DAO/ActiveRecord), а написали свой велосипед, который вызывался моделями фреймворка (сущностями, которые вроде продолжали наследовать фреймвок) :)

    >Если вы утверждаете, что все реализации — плохо, то должны смочь аргументировать такую позицию.

    Я выступаю не столько против самих реализаций, сколько против представления о моделях, как о сущностям, которые ходят в хранилище. Вообще, сущность не должна себя куда-то сохранять/извлекать. Это лишний функционал.

    Хотя да, все эти ходилки в базу мне не нравятся. :) Некоторые я щупал в живую, о принципах некоторых читал в документации.

    Меня полностью устаивает моя ходилка :)

    silex основан на Симфони. У yii 2 8к звезд, хотя это не важно.
    У исходников php 10к звезд.
    Но это же не значит, что php менее популярен за свои фреймворки. :)
    Да и звездочки можно накрутить.

    Звездочка — это типа понравилось / избранное?
    Что она еще дает?
  • PHP: неправильный путь
    0
    Ого ответили :)

    >Которые нахрен никому не нужны)))
    Ну ок. Будем велосипедить. Зачем тогда фреймворки? :)

    Ответьте на https://habrahabr.ru/company/mailru/blog/308788/#comment_9787704
    :)

    > Не согласен. Лишняя сущность — это хлебные крошки, например.

    Она кушать не просит. Не хочешь — не пользуйся. :) Это просто методы для добавления / получения пунктов.

    > А виджеты — полезный инструмент.

    Но и дополнительная сущность. Из-за того, что контроллеры предполагается использовать только 1 раз.

    >))))) Жесть…

    А разве нет?
    MVC во фреймворке, отдельно MVC в виджетах, хотя это можно совместить.

    >Затем, что несете полную ахинею).

    Пруф, что виджеты — лишние и это пятое колесо?
    А у Вас своего мнения нету и мозгов?
    Да и вряд ли такое будет написано где-то, все придерживаются генеральной линии партии.
    Да и смысл, что будет написано против? Вон создатель PHP говорит, что мейнстримовые фреймворки не совсем гуд, это ж не останавливает фреймворкопоклонников :)

    >неверное понимание именно у вас

    https://ru.wikipedia.org/wiki/Model-View-Controller

    «Model-view-controller (MVC, «модель-представление-контроллер», «модель-вид-контроллер») — схема использования нескольких шаблонов проектирования, с помощью которых модель приложения, пользовательский интерфейс и взаимодействие с пользователем разделены на три отдельных компонента таким образом»

    «Начинающие программисты (особенно в веб-программировании, где аббревиатура «MVC» стала популярна) очень часто трактуют архитектурную модель MVC как пассивную модель MVC: модель выступает исключительно совокупностью функций для доступа к данным, а контроллер содержит бизнес-логику.»

    На самом деле это не что-то особенное, а здравый смысл разделить код на уровни.

    >mvc — не единственный паттерн, да к тому-же не самый удобный (hmvc, mvvm иногда намного удобнее

    Я даже не о паттерне говорю, а о самом подходе к разделению кода. Все остальные подходы, это развитие.

    >у вас тоже вызывается только 1 «контроллер» — index.php, в котором вы вызываете виджеты (которые называете почему-то контроллерами).

    Что Вы пристали ко мне с 1 «контроллер» — index.php?
    Вам сторонний человек с лагеря фреймворков указал, что Вы ошибаетесь.

    >Итог — путаете сами себя

    Я как раз не путаюсь в своем коде.
    А фреймворки путают своими сущностями.

    > выставляете себя на смех публике

    О боже, напугали. :)

    >Тогда и nginx является контроллером приложения, верно? Или все-таки нет? Если нет — почему? «Ведь туда поступает запрос.»?)))))

    Если все делить на 3 из MVC и смотреть широко, то да.
    Кстати, в nginx можно писать логику, чтобы не поднимать каждый раз приложение: memcached | lua
    Есть приложения сами себе сервера.
    Даже php может быть сервером.

    >Тогда с чего ваши «виджеты-контроллеры» стали «контроллерами»? В них ведь запрос не поступает — они получают данные от index.php. Значит они не контроллеры, а именно виджеты. Вернулись к исходной точке — у вас 1 контроллер и куча виджетов…

    Это Вы хотите меня говном обмазать. :)
    Контроллер может вызывать другой контроллер.
    Это есть и в фреймворках, но не афишируется.

    >Возможно, но разве я не прав? Вы же сами привели это утверждение ;)

    Я имел в виду исходники приложения в *.php
    Если доводить до абсурда, то нужно говорить, что php без ОС работать не может :)

    >Ну а уж если очень-очень нужен — берем composer и подключаем любой удобный

    Тогда будет зоопарк.

    >То-же самое касается работы со статикой, с внешними сервисами, с почтой и пр.

    Пихать поддержку АПИ внешних сервисов глупо и никто этого не требует.

    >пережиток прошлого, нужный был для seo, от которого уже почти все отказались

    И сейчас нужен, даже микроформаты для облегчения понимания ПС для этого вышли.
    И прежде всего нужно думать обо удобстве пользователей, а не ПС.

    >))) говорит человек, который запихивает в ядро(!!!) атрибуты cms…

    Линукс тоже имеет монолитное ядро.
    Это можно вынести в модуль ядра, не важно. Важен факт, что это из коробки.

    >Иногда да

    А, ну тогда ок. Аргументов больше не имею, если Вас все устраивает :)

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

    Пользователи получают устаревшую / сломанную закешированную версию. Ну ок :)
    Это не настолько трудно реализовать.

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

    >Например, чтобы добавить такой запрос во внутреннюю статистику. Если вам подобные задачи в диковинку — это не значит, что другим они не нужны.

    Можно подписаться на событие… :)

    >Расшифруйте вопрос.

    Страничка собирается на основе ответов из кода разных поставщиков.
    Как узнать, что это та самая страничка, что пользователь получил в прошлый раз? :)

    >В целом понятно, что вы просто уперлись и не хотите даже думать.

    Плюсы фреймворков не перевешивают их минусов для меня. :)
    И прежде всего с позиции разработчика, который пишет код для себя (о чем и сказано в статье)

    Но за дискуссию спасибо.

    Я ни кому не рекомендую использовать мою самопись:
    http://blog.kpitv.net/article/когда-будет-публичный-релиз-ядра-15373/
    Просто говорю, что многие вещи реализовать легче на самописи, нежели на фреймворке.
    Код, по сути, писать нужно и там, и там.
    Кто совсем не хочет велосипедов — тому использовать типичные решения.

    >Но выставлять себя на смех как-то глупо.
    Та смейтесь, смех продлевает жизнь :)

    >считаете, что сторонние библиотеки априори зло
    Я такого никогда не говорил. Я выступаю с другой точкой зрения…

    >но он точно не подойдет под что-то более-менее приличное
    Я не говорю, что мое ядро так сходу и подходит и никого не заставляю им пользоваться. Но по крайней мере с меню и хлебными крошками париться не нужно.
    Но и фреймворки сходу не подходят.
    Разница в том, что свой код можно легко оптимизировать под задачу, а фреймворк придется подпирать костылями, чтобы он не упал на велосипед, на котором мы объезжаем в том числе и подводные камни:
    https://yandex.ua/images/search?text=%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0%20php%20%D0%B2%D0%B5%D0%BB%D0%BE%D1%81%D0%B8%D0%BF%D0%B5%D0%B4%20%D0%BA%D0%BE%D1%81%D1%82%D1%8B%D0%BB%D0%B8

    >Я уверен, что на нем будет сложно сделать даже реалтайм-чатик

    Вряд ли его нужно делать и на php-фреймворке.
    Но вообще, а в чем трудность отвечать на запросы пользователей?

    >не говоря уже о каких-либо соц.сервисах

    Соцсети предоставляют сильно обрезанные возможности

    >Например, сейчас я занимаюсь задачей рекомендаций пользователям определенного контента.

    Пользователь запрашивает такую рекомендацию? Каким образом? Просто например в ФБ эти рекомендации накрученные самим ВБ :)

    >Используемый инструментарий: nginx, php, mongodb, rabbitmq, redis. Может-ли ваш фреймворк мне чем-то помочь? Очевидно — нет.
    Такие технологии не представлены в ядре (модулях ядра) (об этом написано по ссылке почему я никому не предлагаю свое ядро). И у меня не фреймворк. А просто ядро.

    Но это можно реализовать сторонним кодом в случае необходимости.

    У ядра будете просить только конфиги и чтобы оно строило ключи для кеша редиса (если это необходимо).
    mongodb будет использовать sql-интерфейс? Если да, то, к сожалению, модуль ядра для БД писался под mysql, хотя, вроде, никакие сугубо mysql фичи не использует. Ну или сторонним модулем.

    mongodb вроде раньше плохо себя чувствовала при на большиой базе. Почему не РСУБД?

    >Но даже для простейших задач вида бложика использовать ваш фреймворк бессмыслено — проще взять готовую cms (практически любую) и вообще не задумываться о всяких меню и хлебных крошках)))

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

    >Мой вывод — вам еще развиваться и развиваться.

    Я больше скажу, всем есть куда развиваться. :)

    >Надеюсь, мой небольшой троллинг даст понять

    А-ха-ха. Тролль троллит тролля. :) (Но я себя троллем не считаю)

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

    Ну да, и используется теми, кто сам не может реализовать архитектуру, об этом тоже сказано в статье :)

    >Практически уверен, что его можно описать десятком строк в composer.json и тогда получится примерно 1кб ;)

    С таким подходом код вообще писать не нужно.
    Подключаешь composer и получашь кнопку «Сделать все хорошо».
    Только этот код должен кто-то в composer положить. :)
    Да и разбираться с этим зоопарком дольше, чем самому написать.

    По неоткомментированному утверждению из предыдущего комментария:
    А на фреймворке пишут говнокод или только радугу?
    Зависит ли говнокодистость больше от самого разработчика, нежели от того, на чем он пишет?
    Просто о PHP сложилось мнение, что это язык говнокодеров. Хотя на нем пишут и нормальные программисты.
  • PHP: неправильный путь
    0
    >Вполне возможно, только в статье вы не рассмотрели Repository, DBAL/DAO.

    Я рассматриваю шире. А все эти DBAL/DAO/ActiveRecord — это хождение в базу. И так рассматривают фреймворки, а не я.

    >Вполне возможно, только в статье вы не рассмотрели Repository, DBAL/DAO.

    Это реализация хождения в базу. Я говорю, что неправильно рассматривать модель — как хождение в базу. Смысл мне перебирать все реализации хождений в базу, если я выступаю против их всех?

    >В Symfony нет своей имплементации M из MVC

    Ну и что, что нету. Под M все равно понимается хождение в базу. Symfony используется в связке с Doctrine чуть реже, чем всегда?
    Пускай уберут в википедии упоминание, что они MVC в первом предложении, или там же укажут, что M у них как бы и нету. :) Хомячки ведутся на модные слова.

    >Что на счет Zend

    Каюсь, что упустил.
    Он тоже MVC:
    https://ru.wikipedia.org/wiki/Zend_Framework

    Микрофреймворки / малоизвестные не рассматривал.
    Так как малоиспользуемых много и смысла нету, я больше противник дурости в мейнстримовых (разрекламированных). Некоторые микро — это обрезки Симфони и Ларавел.
  • Недоступный веб: как мы развели такой бардак
    0
    Я не о программистах, а о пользователях (основываясь на рисунке из поста https://habrahabr.ru/post/309076/#comment_9787696 )
  • Недоступный веб: как мы развели такой бардак
    +1
    Для меня эти люди молодцы.

    Инструменты? Они скорее второстепенны. Раньше интернетов не было и люди как-то адаптировались (не к интернету).

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

    Но это ни к коем случае не должно урезать возможности обычных людей.

    Вот у нас в Украине сейчас начали школьную псевдореформу, якобы тупенькие детки не справляются с такой сложной программой и ее нужно адаптировать к современным реалиям.
    Что предлагается убрать:
    у 2-му класі: строить круг заданного радиуса;
    у 3-му класі: знать определение периметра;
    у 4-му класі: понимать, что движение тел описывается с помощью 3 взаимосвязанных величин: путь, скорость и время.
    требования к умению слагать значительно послаблят, что-то вроде в первой классе не обязательно уметь слагать без перехода 20!
    также (что было бы логично из предыдущего «покращення») во втором классе нужно знать табличку умножения только до 5. (не знаю, задевает ли это скажем 2*6, так как по логике вещей, это уже умножение выше 5 :) ).
    не будет замера скорости чтения

    Нужно ориентироваться не на слабаков, а на нормальных. Чтобы слабаки доганяли. Как в спорте. Не нужно отменять естественный отбор.
  • Недоступный веб: как мы развели такой бардак
    0
    Многие сайты во многих (некоторых ?) случаях неправильно поддерживают масштабирование из-за багов браузеров.

    Если плохо читать 90% сайтов, то может стоит настроить браузер на бОльшие шрифты / использовать пользовательские стили?

    Вот даже такой псевдоавторитет как мордокнига чихала на пользователей, что тогда говорить о Васе Пупкине с его хоумпаджем / магазином / блогом. :)