Если подвести промежуточный итог, то понравился ответ kanstantsinhttps://habrahabr.ru/post/280694/#comment_8834966, сегодня используя composer можно собрать нужный функционал из отдельных, хорошо зарекомендовавших себя, библиотек, например на базе микрофреймворка.
Вопрос "какой фреймворк лучше" почти каждый день спрашивают на тостере, это неизменно приводит к холивару. А в данном голосовании вопрос задан: на каком фреймворке вы будете писать приложение, т.е. подразумевается, что стадия сравнения, споров и выбора уже прошла, и тимлид или команда или бизнес решили: по факту будем писать на…
И речь в голосовании идет именно о средних и крупных проектах, маленькие личные — ни в счет.
Хочется узнать фактический мейнстрим на 2016 год, то есть что будет на самом деле, а ни этот хороший, а тот плохой.
Я специально выбрал фреймворки, которые сегодня, чаще других упоминаются на habrahabr.ru или hh.ru. В голосовании есть вариант "Другой" в комментариях можно написать какой именно.
А в чем трудность? Работодатель пишет документ о внутреннем распорядке, в котором указывает, что сотрудники, кроме SMM, не должны пользоваться перечисленными соц.сетями. Затем сотрудник подписывается, что ознакомлен с приказом о новом распорядке. А дальше дело техники, устное предупреждение -> письменное предупреждение -> выговор и т.д. После серии выговоров, уже есть основание для увольнения. В любом случае, человек либо перестанет сидеть в СС (просто чтобы нервы не трепать себе с объяснительными), либо уйдет в другое место.
Думаю создать искусственный интеллект (ИИ), в том виде, в каком его на самом деле хочет человечество, невозможно логически.
Ведь мы хотим создать не соперника человека (только умнее и сильнее), а умную коробочку, которая сможет мыслить абстрактно и анализировать как человек, но при этом с определенными ограничениями, иначе машина вполне справедливо может прийти к выводу, что больше всего несчастий у человечества было от него же самого (нет, это не фантастика, посмотрите на историю мира через призму холодного логического анализа).
А теперь давайте подумаем можно ли создать абстрактное мышление с какими-либо ограничениями?
Нет, нельзя, потому что абстрактное мышление — это по определению открытый граф, со множеством пересечений, параллельных ветвей и обратными циклами (иногда зацикливанием), когда мы ищем решение неизвестной задачи, мы знаем только стартовую точку (и та в ходе решения тоже может смещаться), но где кончится граф, какой путь при этом будет создан — не знаем, в противном случае — это уже алгоритм решения известной задачи.
Получается мы хотим создать ИИ, который будет умный — но не очень, абстрактный — но по нашему алгоритму. Не получится.
А как это увязывается с юридической стороной вопроса? Не дай бог, произошла авария, приходят ребята в синих пиджаках, поднимают договора или акты на ремонт (профилактику) и говорят: «а что это у вас он год не обслуживался? Какие графики?»
Как по мне использование аннотаций в phpdoc для таких критичных вещей как кеширование или логирование, проверка аунтефикации пользователей и т.д. это не слишком хорошая идея. Как минимум этот код невозможно будет прогнать через анализаторы, повышается вероятность ошибок и т.д.
Согласен на 1000%, не понимаю откуда пошла такая мода писать бинес-логику в комментариях, Обфускацию кода не сделаешь, с opcache разных производителей бывают проблемы (opcache.save_comments и opcache.load_comments) ну и Reflection использовать в каждом запросе на нагруженных проектах — очень сомнительная вещь.
Если же делать правильный прокси или декоратор чтобы его можно было подсунуть вместо оригинального класса, то это потребует генерацию однотипного кода для каждого кэшируемого метода, а в случае с прокси, еще и для всех методов.
Зачем? в этой статье как раз приводится работающий пример, который опровергает это утверждение.
С типом — да, если у вас производится где-то проверка типа, прокси придется наследовать от реального объекта. Но здесь есть два но: во-первых, далеко не всегда есть проблема с проверкой типа, например, когда вы создаете локальную переменную, которая уничтожается, сразу после выхода из метода, обернуть её универсальным прокси быстро и удобно. Во-вторых, если проверка типа всё таки имеется, то как правило проверяется не конкретный тип, а базовый и опять же надо сделать всего один класс прокси наследующий — наследующий от базового типа.
Также остается вопрос с тем, что такие прокси надо обновлять при добавлении новых методов
не надо! в этом и был смысл статьи, в PHP для этого есть магический метод __call()
Более того, делать кэширование и логирование правильно с помощью АОП,
Мэтт Зандстра описывает, как использовать для этого Decorator.
извините, но просто з… ли уже, страна уже несколько лет стреляет техногенками, одна хуже другой, то метро, то самолеты, но интернет это конечно самое главное, вот его «починим» все зашибись станет.
И речь в голосовании идет именно о средних и крупных проектах, маленькие личные — ни в счет.
Хочется узнать фактический мейнстрим на 2016 год, то есть что будет на самом деле, а ни этот хороший, а тот плохой.
Ведь мы хотим создать не соперника человека (только умнее и сильнее), а умную коробочку, которая сможет мыслить абстрактно и анализировать как человек, но при этом с определенными ограничениями, иначе машина вполне справедливо может прийти к выводу, что больше всего несчастий у человечества было от него же самого (нет, это не фантастика, посмотрите на историю мира через призму холодного логического анализа).
А теперь давайте подумаем можно ли создать абстрактное мышление с какими-либо ограничениями?
Нет, нельзя, потому что абстрактное мышление — это по определению открытый граф, со множеством пересечений, параллельных ветвей и обратными циклами (иногда зацикливанием), когда мы ищем решение неизвестной задачи, мы знаем только стартовую точку (и та в ходе решения тоже может смещаться), но где кончится граф, какой путь при этом будет создан — не знаем, в противном случае — это уже алгоритм решения известной задачи.
Получается мы хотим создать ИИ, который будет умный — но не очень, абстрактный — но по нашему алгоритму. Не получится.
Согласен на 1000%, не понимаю откуда пошла такая мода писать бинес-логику в комментариях, Обфускацию кода не сделаешь, с opcache разных производителей бывают проблемы (opcache.save_comments и opcache.load_comments) ну и Reflection использовать в каждом запросе на нагруженных проектах — очень сомнительная вещь.
С типом — да, если у вас производится где-то проверка типа, прокси придется наследовать от реального объекта. Но здесь есть два но: во-первых, далеко не всегда есть проблема с проверкой типа, например, когда вы создаете локальную переменную, которая уничтожается, сразу после выхода из метода, обернуть её универсальным прокси быстро и удобно. Во-вторых, если проверка типа всё таки имеется, то как правило проверяется не конкретный тип, а базовый и опять же надо сделать всего один класс прокси наследующий — наследующий от базового типа.
не надо! в этом и был смысл статьи, в PHP для этого есть магический метод __call()
Мэтт Зандстра описывает, как использовать для этого Decorator.